[Info-vax] OpenVMS printing to PDF

[Stephen Hoffman]

On 2015-05-18 22:05:16 +0000, Dirk Munk said:

> Stephen Hoffman wrote:
>> On 2015-05-18 20:51:52 +0000, Dirk Munk said:
>> 
>>> The functionality that I mean is the ASCII > Postscript conversion,
>>> that could be easily adapted for a ASCII > PDF conversion. That part
>>> of DCPS shouldn't have to output to a printer, it could also produce
>>> files.
>> 
>> You are seriously are proposing running file-format conversion
>> processing through a symbiont?   Not via a callable API such as CDA$ and
>> not via a DCL command such as CONVERT /DOCUMENT?
>> 
> 
> Good question.
> 
> Using a symbiont would be possible. That is standard way to produce pdf 
> files in Windows. I have several pdf printer applications on my PC. In 
> any application that has a "print" command, I can choose a pdf printer, 
> enter a file name, and I will get a pdf file.

It's the standard way because Windows never really had support for 
Postscript or PDF, and never looked at integrating the document 
handling.

Rather than using the printer for this processing, imagine if your 
tools all had export or save commands or output options, and that wrote 
the format directly?

Imagine if you were programming some tool, and whether you'd want to 
have to route your work through the symbiont, or if you'd rather call 
some routines to create and process the data more directly — on some 
systems, the standard "print" and "save" dialog sequences available to 
applications provides the ability to export PDF, for instance.  No 
queues required.

Or for that matter, imagine if you were architecting this requirement 
anew.  Starting fresh.   What's the most straightforward and flexible 
approach, here?  If you're doing conversions, why not just call the RTL 
directly?   Vastly simpler, synchronous, direct path for error 
reporting, and generally just easier to deal with.  Use the RTL from 
the CONVERT /DOCUMENT command, and from the print symbiont, so there's 
one copy of the code around.

As for the queue manager, try using the queue manager for symbiont 
operations.  Try it sometime.  It's... interesting.   $getqui is 
interesting to work with, too — it works, and it's consistent, but it's 
also one of the more arcane calls to use on OpenVMS, along with a few 
of the SMG$ calls.   (Folks using the lexical have had some issues, 
such as nested f$getqui calls, too.  Not easy to deal with.)  Would a 
symbiont-based file-conversion approach work?  Sure.   Getting 
conversion or formatting errors back from the symbiont — assuming the 
symbiont doesn't just tip over, as was once far more common — and leave 
you with some cryptic messages about the crash text arriving at the job 
controller — would be an interesting problem.  No easy way to tie those 
back to the source file, short of passing messages through mailboxes or 
via some sort of an analysis file.

Being able to register a callback from the conversion RTL via an API is 
just... easier.

> Convert/document would be fine too.
> 
> A real full blown application would even be better. I think I've 
> mentioned this before. Suppose you would create a form for a bill with 
> a word processor, or with a pdf editor, that form would have fields, 
> and you would have a utility comparable to FMS to fill those fields 
> from an application, that would be the kind of pdf utility I would like 
> to see.

If I understand your request, PDF already provides that capability.  
You can generate a PDF form — your input view — and can then open that 
PDF and enter text into it, and the PDF tool can then save your results 
as necessary.





-- 
Pure Personal Opinion | HoffmanLabs LLC