[Info-vax] OpenVMS printing to PDF

[Dirk Munk]

Stephen Hoffman wrote:
> 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.
>

Seems to me as if Windows has a print API, and that every printer 
manufacturer has to write his own driver using that API. Adobe used to 
have a Postscript printer driver for Windows, but that driver hasn't 
been update for a decade. Other Postscript printer manufacturers also 
produce Postscript driver. It's al a bit odd, Postscript should be 
universal, and the driver should be able to adjust to the printer 
capabilities.


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

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.