[Info-vax] OpenVMS printing to PDF

[Jan-Erik Soderholm]

Dirk Munk skrev den 2015-05-20 15:32:
> 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.
>

Yes, but step 2 is not needed if you did the form youself.
You probably already know the field names.

And the application can of course just as well write the FDF
file directly. It is a flat text file with a rather simple format
(at least in the example). So step 3 might not be needed either.


> 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.

Probably preferable to not do that 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.

Yup, nice. But no absolute show-stopper if not available.

> 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.

Doesn't *has* to be done in the context of the application process.

The "application" might create the FDF file for sevaral 1000s PDF files
and then send that file over to some "server thing" that does the
actual merge of the PDF form and the FDF data.

It also depends on what should happen with the finished PDF files.
Maybe mailed out to some receivers/customers. Could be better not
to have the application waiting for that to happen.

You also have to concider how to adapt old applications and making
that process simple might be worth something.

>
> 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.

The form marge has to be done somewhere. And if it is done in the
context of the application process or in another process probably
dosn't make that a big difference.

There are also such things as temporarily stopping the PDF
creation without stopping the applications as such.

And going from "nothing" to a CLI/batch tool is a step large
enough and certenly usuable for me... :-)

Jan-Erik.