RE: PDF Limitations?

[Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>]

Hello James,

> You are absolutely correct.  However, not all hope is lost.  We have a 
> customer that routinely emails pdfs that were created using lp5250d.  Here is 
> the relevant part of the configuration:
>
> outputcommand = scs2ascii > /tmp/output.ps ; ps2pdf /tmp/output.ps 
> /home/user/pspdf.pdf

Lets see... scs2ascii will take an SCS document from an output queue and 
convert it to plain ASCII text (.TXT document).  Your customer then takes 
that and runs it through ps2pdf (?!) as if it's PostScript?!

The result will be a PDF!  Just like scs2pdf creates, but it'll take 
longer because it's less efficient and is based on the assumption that 
ps2pdf will know how to treat a plain text document, despite that it's 
designed for PostScript documents.

Why don't you use just scs2pdf?! Or if you must convert to plain text in 
the interim, why not use a2ps or enscript to convert the text to 
PostScript before running ps2pdf?!

Not that ANY of this has anything to do with my concerns, mind you...


> we have an instance of lp5250d running for each user that wants to email 
> these pdfs.  The user simply moves the spooled file to their appropriate out 
> queue and then attaches the file that is created to their email message.

That addresses my concerns -- assuming that it's legal in your environment 
to have a different output queue for each desintation e-mail address.

For example, I have an e-mail address for a vendor in my VENMST file. When 
I want to send him a PO, I create a PDF document and send it to his e-mail 
address.

Using your method, I'd have to a separate output queue for 6000 different 
vendors!  That's a lot of output queues!


> We have another customer that needs to archive some large reports that are 
> created monthly.  He needs to be able to search the archives as well, so a 
> searchable format is critical.  He has three reports, so we created three out 
> queues each with a different name for the resulting pdf.  This config looks 
> like:
>
> outputcommand = scs2pdf> /home/samba/<reportname>-`date 
> +%Y-%m-%d-%H-%M-%S`.pdf

That's actually a good idea... However it assumes that no two reports will 
be made at the same second -- which isn't a good idea.  Particularly since 
if that happens, there won't be any error message, you'll just simply 
trash the first one and replace it with the second one.

> I've thought of doing the same thing.  My thoughts have been to create a 
> special type of out queue that could send additional information to lp5250d. 
> I don't want to make an iSeries version of scs2pdf because quite honestly, 
> there is far less that I can do with the results on the iSeries.

Really? What can you do with the results on a Linux box that you can't 
do on the iSeries?