[Info-vax] OpenVMS printing to PDF

[Dirk Munk]

Jan-Erik Soderholm wrote:
> 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.
>

Maybe, but extracting the field names and attributes doesn't rely on
human accuracy. And the PDF file may have been produced by an entirely
different party. Such a utility is more save.


> 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.
>
Mail messages are put in a queue, and handled by the mail program. I
once wrote a DCL procedure that constructed a mail message (incl. all
headers etc.), and mailed it using SFF if I remember correctly. It was a
bulk mailing process that zipped and mailed bills.

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

I agree, it can be done both ways. However doing it in one step means
far less disk IO, so it should be quite a bit faster. Compare it with
the sort utility, you can use sort on its own, or call it from within an
application. The VMS PDF merge application could also be callable or run
on its own.

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