Hi all,

I have seen this topic thousand's of times and I still have no
clue how to do this very simple thing.

1) I have a pdf files with form fields on it.

2) From vb6 I want to put data in thoses fields.

That's it.

I have the AcrobatSDK, the FDF toolkit, the iTextSharp
(or whatever) C# dll that works great in VB.NET, all of this
and I can't put data in a single text field on a PDF file,
the  deFacto state-of-the-art technolory for rendering forms
elcetronically, and I am about to give up 20 years of
progrramming to live out my life in tibet on some moutain top,
far away form PDF, FDF, or any other kind of file whatsoever.

What is the deal with PDF files and total inability to communicate
data back and forth with them in a simeple, clear, intuitive manner?

Is it me?  If it is, that's OK, I can handle it.  Just someone please
for the love of pete tell me how to put my data on a pdf file without
Acrobt of some third  party AX or that incomprehansible FDF toolkit.

Thanks,
kpg

Jun 2008 14:32:38 -0700 bearing the following fruit:

I don't have any answers, personally I think PDFs should be
die a quick death. I see no advantages in them but plenty of
disadvantages.

--
Jan Hyde

https://mvp.support.microsoft.com/profile/Jan.Hyde

hmmmm...not exactly the affirmation I was looking for...

...the only advantage I know of is ubiquity.

Well, there's that and the fact that it is an open "portable document
format" which means it works on Linux and MAC as well as Windows but
most folks here aren't interested in stuff like portability or open
versus proprietary formats.

Frank

Jun 2008 14:28:52 -0700 bearing the following fruit:

I don't mind the format nearly as bad since someone pointed
me towards Foxit.

Most of clients want PDF because they believe it cannot be
altered. Unfortunately it's far, far easier than they
imagine.

I've only ever seen a couple of PDF as forms, oddly they
would not work with Adobe's reader, but work perfectly with
Foxit. I'm not sure if there is any advantage to PDF when it
comes to forms, after all HTML is just as universal.

Still, none of this is getting an answer to you question...

J
--
Jan Hyde

https://mvp.support.microsoft.com/profile/Jan.Hyde

Hey, I'll bow down and kiss it's feet if I could just put some
data on the stupid forms.

I've generated PDF from scratch in VB6: text, fonts, and images -
so to get data on those I just add it as text.  Now I'm in  a
position where it's advantageous to use already designed forms
with text fields on them.

So I could open the form as binary and write my own PDF parser,
having to handle all the common variants, as well as compression
and whatever security encryption is in place, but why re-invent
a very big wheel?  So I think I'll download the AcrobatSDK and
be form filling in hours - well not so much.

For my .net web based projects I use the iTextSharp dll and it
works well.  There are a bunch of AX available at a price, but I
don't trust them to keep up with future changes.  I would rather
Adobe provide a component, but all they offer is an FDF AX or the
newer XML method both which require Acrobat Reader.

That Reader is required is really a moot point, since the client
will need that to actually see the PDF anyway, but for some
reason I can't get it work right on my production machine.  I
realize this is most likely a condemnation of me more than the
reader, but I was just a little surprised at how large and complex
they whole PDF  generation thing has become (or is).  A visit to
Adobe's web site and all the enterprise and collaboration emphasis,
server products, on and on, WTF?  I'm glad they're making money
and just wish I could populate their forms without a PhD in
acrobat.

Geez, I'll go back over the FDF/XML documentation again, but
I ain't gonna like it.

kpg

OK.

For anyone interested, and I assume that are very few of you,
I have actually cracked this particular nut concerning FDF,
XFDF and PDF population form VB6.

As it turns out my assumption of how it all works was a little
off, which caused me great confusion in the end.

It seems once you generate an FDF file, or an XFDF file (which
is the XML version of the original FDF format) that file becomes
the one that is opened by the reader (there is a reference in the
FDF file to the PDF document) and the reader merges the data with
the blank PDF file.

So, for a simple PDF file with two fields, Text1 and Text2

FDF:

    Dim FdfAcX As FDFACXLib.FdfApp
    Set FdfAcX = CreateObject("FdfApp.FdfApp")

    Dim fdf As FDFACXLib.FdfDoc
    Set fdf = FdfAcX.FDFCreate

    fdf.FDFSetFile "c:\pdf\Application.pdf"

    fdf.FDFSetValue "Text1", "myValue1", False
    fdf.FDFSetValue "Text2", "myValue2", False

    fdf.FDFSaveToFile "c:\pdf\Application.fdf"

    fdf.FDFClose

XFDF:

    xfdf = "<?xml version=""1.0"" encoding=""UTF-8""?>"
    xfdf = xfdf & "<xfdf xmlns=""http://ns.adobe.com/xfdf/""
xml:space=""preserve"">"
    xfdf = xfdf & "<f href=""c:\pdf\Application.pdf""/>"
    xfdf = xfdf & "<fields>"
    xfdf = xfdf & "<field name=""Text1"">"
    xfdf = xfdf & "<value>myValue1</value>"
    xfdf = xfdf & "</field>"
    xfdf = xfdf & "<field name=""Text2"">"
    xfdf = xfdf & "<value>myValue2</value>"
    xfdf = xfdf & "</field>"
    xfdf = xfdf & "</fields>"
    xfdf = xfdf & "</xfdf>"
    Open "c:\pdf\Application.xfdf" For Output As #1
    Print #1, xfdf
    Close

Excuse the fact that I'm not using an XML object to generate
the xml file, as would be the normal case, this is just an
example of the XFDF format.

Then a simple shellopen to the fdf or xfdf file opens Acrobat
Reader with the data filled in, and the user is free to admire
or print it at their leisure.

I like the XFDF technique due to the lack of a required AX,
but I think the client will need a fairly new version of reader,
the least of my worries.

kpg

One last beat on this dead horse.,,

The FDF file can be generated without the use of the
FDF AX, as it is just a text file itself.  This would,
I suppose, remove the "need newer reader" requirement,
with the caveat that the now nearly retired FDF format
does not loose backward compatible status with new
readers.

kpg