[Info-vax] OpenVMS printing to PDF

[Stephen Hoffman]

On 2015-05-20 09:11:55 +0000, Dirk Munk said:

> Stephen Hoffman wrote:
>> On 2015-05-19 23:23:48 +0000, Dirk Munk said:
>> 
>>> 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.
>> 
>> So go write it, then.
>> 
>> With what I'm working with, you create the display as needed using the
>> interface builder within the development tools, and then export the
>> resulting display to PDF.   The applications don't know they're doing
>> something any different than writing to a display.  That's with the
>> baked-in PDF capabilities on the platform, and the related integration
>> that's available.
>> 
>> For many applications rendering your pages via HTML5 would be a far more
>> typical approach, then generating PDF files from that.
>> 
>> Related:
>> <http://stackoverflow.com/questions/923885/capture-html-canvas-as-gif-jpg-png-pdf>, 
>> 
>> <http://www.html5rocks.com/en/tutorials/forms/html5forms/>,
>> <https://msdn.microsoft.com/en-us/magazine/hh547102.aspx>,
>> <http://diveintohtml5.info/forms.html>,
>> <http://www.codeproject.com/Articles/466362/Blend-PDF-with-HTML>, etc.
>> Some of those links are comparatively ancient, too.
>> 
>> Rolling your own FMS or DECforms solution — unless you're doing
>> translation or support or a conversion for existing OpenVMS sites, maybe
>> — will have to compete with what's available, obviously.
>> 
> 
> Seems to me as if we have a misunderstanding. I'm not suggesting using 
> PDF as a way of interactive data entry, although that would be possible 
> I guess.

Or we have a case where you have a particular solution where FMS is 
still appropriate — go build it — and I'd use different tools and 
approaches.  You like Windows interfaces and using the symbiont, and 
that is very far from an approach I'd design or would prefer to use — 
but maybe you can garner a customer base for it, so go build it.  You'd 
use FMS and similar tools, and I'd probably avoid that as most folks 
are interested in rendering forms with rather more control over the 
display and quite possibly with images and watermarks and related — but 
again, there might be a market for folks that like the FMS-style 
text-only embedded-code approach, so go build it.

Now before you go build it, I'd suggest a little market research into 
how folks — those not using FMS or DECforms — are doing these tasks 
now.  What packages and tools are in use, and what the prices and 
options are.  Maybe have a look at 
<http://www.fytek.com/products.php?pg=pdfrpt>, for instance.   
Definitely have a look at what HTML5 can do here, too — maybe not on 
OpenVMS, but it's a viable approach on various other platforms.  
(Remember my comments about how easy it can be to instantiate a browser 
window within an application, on some platforms?)

Many folks have their customer billing integrated into their existing 
accounting or ERP system, and there are commercial and open-source 
options there: 
<https://en.wikipedia.org/wiki/List_of_ERP_software_packages> 
<http://sourceforge.net/projects/postbooks/>.   For this case, this 
integration means that the OpenVMS servers pass the event details along 
to the accounting or ERP system, or pass the details to the box that 
can compose and print bills or invoices or inserts, and let that deal 
with printing invoices and bills and such.   Oracle and any number of 
other vendors have report writers and the invoicing- and insert- and 
paperwork-generation equivalents of the old-time mail merge programs, 
too.

But again, go build this tool.  You see it.  I, well, I don't see what 
you're building here, nor how it's particularly going to attract 
attention.

> With FMS you design a form, and that form has data fields. In your 
> application you can fill those data fields with data from a database, 
> and then issue a command to display the form. The application has no 
> knowledge about the form itself, it just knows the names of the data 
> fields.

Sure.  I'm familiar with the old products and tools, and I would not 
choose to use something like FMS here when there was a better option, 
and I would most definitely not seek to present a product with an 
FMS-like design to most folks.  I'd likely render this via HTML5, 
though I'd also look to use the local lowercase-W window system to 
render some documents — what I work with on some platforms can and does 
allow an application to create a display or a canvas, fill in the 
contents, and then print it — without rendering the lowercase-W window 
to the user.  HTML5 can do this, as well.  LaTeX or PostScript or such 
could be used, but that tends to get rather fussy — I'd rather use a 
graphical form editor, tag the fields, and then have the "render" call 
in the application deal with everything.  The form editor can and 
probably should include the database queries necessary for the 
particular operation, which are then triggered when the form is 
rendered.  (On thinking about this a little more, Oracle and other 
databases all have these tools, too.)

> Of course FMS also supports interactive data entry, but I'm not 
> referring to that functionality, it's just about showing data.

You seem to be misunderstanding my comments about HTML5, as HTML5 can 
be used to render and display data within the context of an 
application, and that display can then be used for printing.  (See the 
URLs listed above — not-human processing is the target for a whole lot 
of HTML rendering and of HTTP and HTTPS traffic, tjhese days.   Yes, 
this is a different approach than FMS and the usual FMS subroutine 
calls that are integrated within an application and the FMS editor 
widget, and I usually find the newer rendering and display tools to be 
superior.    You also seem to be unfamiliar with windowing systems that 
can also be used for rendering and display and PDF export.  That's 
common on some platforms.

> If we could do the same thing with PDF, then you could design a PDF 
> form with any tool you like, and then use a somewhat FMS-like utility 
> to make the data fields in that form available to an application. The 
> application can fill the data fields, and the issue a command to write 
> the PDF page/file.

Again, this entirely feasible on various modern platforms.  You seem to 
be using Windows and OpenVMS as your benchmarks here, which is 
unfortunate for this particular discussion, as neither platform has 
particularly robust Postscript or PDF support integrated into the 
platform.  Windows is apparently getting better here, but it's been a 
while since I've tangled with PDF on that platform, short of the add-on 
Adobe tools or similar.  OS X and I'd expect Linux both do better, 
here.   VSI has some work to do on OpenVMS in this area, if PDF support 
is your goal.

Yes, FMS works, but it's a whole lot of work for what you get out of 
it. curses and ncurses and SMG and the rest are similarly workable for 
these sorts of tasks, and similarly involve some effort, too.  Though 
the results of text-only conversions and the effort involved with FMS 
or similar — even with the FMS forms designer support, whatever that 
widget was called — tends to limit the interest that most folks will 
have.   For better control, you're headed toward emitting LaTex or such 
— or toward HTML5.  Or toward using any of the existing 
report-generation tools, or using platform-integrated Postscript and 
PDF generation or conversion tools, where that's available.




-- 
Pure Personal Opinion | HoffmanLabs LLC