[Info-vax] OpenVMS printing to PDF

[Jan-Erik Soderholm]

Stephen Hoffman skrev den 2015-05-20 16:54:
> 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.
>
>


Never mind. We live in different realities. And I think my reality
is closer to the actual user needs. This is meeningless.