[Info-vax] OpenVMS printing to PDF

[Stephen Hoffman]

On 2015-05-20 14:09:57 +0000, Jan-Erik Soderholm said:

> Stephen Hoffman skrev den 2015-05-20 15:54:
>> On 2015-05-20 13:32:57 +0000, Dirk Munk said:
>> 
>>> 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.
>> 
>> An HTML5 template is created, with Javascript or other embedded scripting
>> code that queries the database or otherwise fetches the data from the data
>> source or from the URL or from the POST data, and where the local HTML5
>> rendering tool can then generate the completed form into a buffer, and
>> where the rendering tool then generates the PDF from that HTML5.
> 
> Where is that Javascript or "other embedded scripting code" running?

The scripting is running in the web rendering engine.   Rendering 
engines are common on various platforms, and allow HTML processing — 
including the scripting languages — to be embedded into applications.  
This approach is analogous to what FMS would do, but HTML5 is an 
approach using a more standard template mechanism and tools — this when 
compared with something based on FMS-style tools and the FMS rendering.

This is also what a web browser would do, though in this case the 
browser is being operated programmatically and is not displaying its 
processing to a human.  Basically, web browsers are now component tools 
that can be easily and effectively automated and used within 
application programs.

On some platforms, instantiating a web browser window in a GUI and 
creating a functional browser requires ~50 lines of application code 
and a little work in an interface designer — there's certainly a 
shedload of code underneath all that, but that's only of consequence 
when there are bugs or when there performance issues or other such.    
This is for a visible window in a GUI.  Rendering under application 
control doesn't need to create a visible window.  Much like what 
something like FMS would do, when the results are not displayed.

For better and sometimes for worse, there's an ever-increasing shedload 
of code involved in most operations involving recent tools and 
operating systems.  Some call it code bloat.  Some call it "table 
stakes" for a modern environment.

If you're not upgrading and not enhancing your environment, none of 
this is of use to you, of course.  Whether an embedded WebKit or 
embedded PDF conversion tools or otherwise.

> Should the whole RT support for these scripting codes be linked in into 
> each application?

If it's useful for the application, yes, it'd be merged into the 
application.   If not, no.  The APIs for the rendering can be pretty 
easy to use, too.   There's been a whole lot of work to make rendering 
run efficiently, and to make the scripting languages run very quickly, 
too.   Will there be overhead?  Sure.  If there are performance issues, 
then those would certainly need to be addressed.

Are there ways to insert the text into a template PDF?  Sure.  Are the 
OpenVMS tools and callable support for PDF creation and PDF-related 
conversions and for web rendering non-existent?  Ayup.   Would I expect 
to find OpenVMS to be doing this sort of thing in a new environment?  
No.

But if — as my reply was intended to comment on — the goal was a tool 
to perform invoice management and PDF or print merge operations, then 
knowing about the options and the alternatives can be useful.  HTML5 is 
one approach that folks are using here, though not on OpenVMS.

> I do not understand the practical side of what you are saying.

On other platforms, web rendering engines are little more than another 
callable service.

Would I pick an HTML5-based solution over an FMS-style solution?  Yes.  
Does that mean I've eliminated OpenVMS from generating bills or 
invoices or the rest?  Yes.  I'd use the software or the server 
operating system that works best for that requirement.  It may well be 
tied into the ERP or accounting system, or into some server that only 
does forms and forms management processing.

Would I expect to see an HTML rendering engine available on OpenVMS?  
Eventually, yes.    I'd expect to see some PDF-related support before 
then, even if that is "just" CDA support.  This assuming VSI gets to 
stable revenues, and assuming that VSI starts to broaden what OpenVMS 
can provide to existing and to potential new customers.


-- 
Pure Personal Opinion | HoffmanLabs LLC