[Info-vax] OpenVMS printing to PDF

[Dirk Munk]

Jan-Erik Soderholm wrote:
> Dirk Munk skrev den 2015-05-20 12:28:
>> Jan-Erik Soderholm wrote:
>>> Dirk Munk skrev den 2015-05-20 01:23:
>>>
>>>
>>>>
>>>> Indeed a PDF tool can do that. But think of a billing program that
>>>> produces
>>>> PDF output files. Similar to FMS, you first produce a PDF form with
>>>> named
>>>> fields, and then you fill those named fields in your application. When
>>>> the
>>>> form has been completed you write the pdf form, as an individual
>>>> form, or
>>>> all of them as one big file, just as you choose.
>>>>
>>>
>>>
>>> That is mostly what the JetForm siute of applications did.
>>> Used JetForm Design to design a form (Windows based).
>>> Applications created a flat text file with the "data".
>>> Jetform Merge (we used the VMS version) then inserts
>>> the data into the form and (in that case) produced a
>>> PCL5 file to be printed. With logos and barcodes.
>>>
>>> A "PDF form" is usualy something that should be filled in
>>> interactively using the Adobe Reader and is something quite
>>> different.
>>>
>>> Jan-Erik.
>>
>> A PDF form (or FDF)...
>
> The FDF file is not the *form*, it is the data file to be
> filled into the form (which is still a PDF file).
>
>> ...can be filled in interactively of course, but also by
>> an application. Just Google a bit and you will find many
>> applications that can do this.
>>
>
> Something like this, I guess:
> http://www.pdf-tools.com/pdf/pdf-form-filling-flattening.aspx
>
> The popular opensource alternative seem to he PDFtk (PDF ToolKit).
> https://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/
> https://www.pdflabs.com/tools/pdftk-server/
>
> PDFtk would be nice to have ported to VMS. On *my* list this
> comes *way* ahead of a web-browser...
>
> Here is a nice tutorial on the process:
> http://www.myown1.com/linux/pdf_formfill.shtml
>
>
>> There are also quite a number of applications that can read the filled in
>> data from FDF files. Contrary to a web page, a FDF form is rigid,...
>
> The FDF file is not the form. And the usual approach seems to use
> "flattening" in the "fillin" operation. That removes the "forms"
> attributes from the PDF file so that it is not editable using
> simple PDF form tools anymore. It is just a plain flat PDF file.
>
>
>> ...it [FDF] can not change it's appearance.
>
> The FDF file is just a simple specielly formatted PS file.
> There is an exmaple on the tutorial page above.
>
> Jan-Erik.

Yes, PDFtk is getting closer to what I would like to see.

What happens with PDFtk now is this:
1. A PDF form is constructed with some kind of PDF editor.
2. PDFtk is used to extract the field names and field properties in a 
Fields File.
3. A data file is generated, by some kind of application presumably.
4. A special program called fdf_gen is used to combine Fields File and 
the data file to a FDF file.
5. The FDF file is used by PDFtk to fill in the PDF file.

What I would like to see is this:
1. A PDF form is constructed with some kind of PDF editor, no need to do 
this on VMS.
2. Some kind of utility extracts the field names and field properties to 
a Fields File. This can be a VMS utility, and it could check the 
validity of the fields and produce the type of file we need. It could 
also be able to produce files with field definitions that can be 
included in application sources, for instance a file with fields that 
can be included in the Cobol Working Storage.
3. A callable utility (similar to PDFtk) opens the PDF form, the 
application fills in the data fields, calls the utility to transfer the 
contents of the data fields to the form, and then writes a page of the 
pdf file.

Flattening the file to remove the field names etc. could also be a 
callable function.

This is a far more direct approach than the many steps of PDFtk, and far 
more suitable for high volume data processing in my view.