[Info-vax] OpenVMS printing to PDF

[Jan-Erik Soderholm]

Stephen Hoffman skrev den 2015-05-20 14:41:
> On 2015-05-20 02:38:06 +0000, Dirk Munk said:
>
>> I've done some Postscript programming myself a very long time ago, and I
>> still remember some of the basics. Among the things we did was produce
>> Postscript files in a Cobol program, and the resulting file was sent to a
>> Postscript chain-form printer. You couldn't make the pages too complex,
>> because then the printer couldn't process the Postscript fast enough to
>> have the resulting image ready for the next page, and as a result it
>> would insert a blank page.
>>
>> I get your point with regard to the PDF input fields. So after the form
>> has been filled, it should be "flattened", removing all fields, but not
>> their contents of course. However you could also use password protection
>> or another way of protection to avoid some one changing the contents
>> later on.
>>
>> I have a program called Nuance Power PDF Advanced on my PC to create and
>> edit PDF files and forms, so I have a rough idea about all the
>> possibilities with PDF.
>
> I'd suggest using technologies designed and developed the last ~twenty
> years (e.g. HTML, PDF frameworks), but if you wanted to spend the time with
> Postscript or LaTeX or such tools, or if you wanted to do in-line coding
> akin to what was typical with FMS, it'd work.   iOS and OS X can trivially
> generate this stuff, or yes, you can use older tools and then ps2pdf or
> similar.
>
> For Python, I'd likely look to start with something akin to
> <https://bitbucket.org/rptlab/reportlab>
> <http://www.reportlab.com/opensource/>.

I have used ReportLab and it is nice and it works.
But it always created the full PDF from scratch. There
is no way to use GUI tools to create a PDF  form for later
(batch) fillin in some (say VMS) server environment.

A port of PDFtk would work nicely. The only "roadbump"
I saw was some dependences on Java (?).


>  Maybe
> <http://appyframework.org/podWritingTemplates.html>.  But various of the
> systems I deal with are easier here, and in various dimensions — tools,
> SMTP support, etc — so I'd probably not bother trying to get something like
> OpenVMS to drive this whole process, and would RPC or push notify or
> otherwise trigger and transfer either an individual request or a bulk run
> from the OpenVMS server to the host performing the processing, or would use
> a database shared with OpenVMS, etc.  In general and obviously depending on
> the application, some other platform may well be preferable to using
> OpenVMS here.
>
> For OpenVMS, CDA$ conversions would be the typical mechanism for
> something-to-something conversions (maybe text or Postscript to PDF, here),
> but there's little support for "recent" formats in CDA$ (older RTF is about
> the limit) and AFAIK there's no PDF support in CDA or in DECwindows.
> (Though there was a PDF tool mentioned in an early VSI roadmap, that seems
> to have disappeared from the more recent roadmap. I've not seen any mention
> of extensive work in DECwindows, nor a PDF framework, nor PDF tools other
> than what was in the roadmap a while back.  That's probably in the plans
> for "sometime around eventually", but getting the VSI business going first
> is more important.)
>

And, *everything* doesn't have to come from VSI, does it? :-)

Jan-Erik.