RE: AFP Overlay Troubles - box overshadowing text -- MIDRANGE-L

On Wed, 30 Mar 2005 michael@xxxxxxxxxxxxxxxxxx wrote:

I'm doing a bunch of overlay stuff right now...what did you see for file
sizes between a postscript file and the equivalent overlay and merged
text? Did you create the postscript file with the dynamic text in it or
use the postscript file as an overlay? HAd to have the right printers,
right?

I have no idea what the file size of an equivalent overlay and merged text would be since we abandoned the overlay before ever finishing it. I wouldn't know how to check to size of a spooled file anyway. The postscript sizes I can tell you since we are able to "print" those to a file on another machine. Our technique using postscript results in a 13 page file being 228888 bytes (obviously this varies as more/fewer pages are printed and the text changes).

What we did was to create postscript that described the form, read that into the RPG program, and use subprocedures to place the text where we wanted it. That way we were able to use the same programming structure that an externally describe print file would use. The only difference is that there is no overflow, so you have to count the lines yourself. The process is basically this:

1. Read from the IFS the first part of the postscript "form" (in postscript parlance this is called the "header" which is followed by the "script"). So this first part of the "form" includes the header and enough of the script to create the various boxes, lines, logos, etc. that we wanted to show on every page. Since postscript commands can be run any basically any order, we can print anywhere on the page at any time. So storing the static part of the page on the IFS and reading it in makes good sense. That way we can design the form on some other machine and then simply ftp it to the iSeries. Since it is just a plain ASCII file this is very simple.

2. Write to an ASCII file on the IFS the first part of the "form" we just read in, followed by the text we want printed. In order to make the program work as much like using an externally described print file as possible, we created subprocedures to print each field. Then to print the field we just call the function like this:

C        eval   rtncode = print_ps_fieldname1(fieldname1)
C        eval   rtncode = print_ps_fieldname2(fieldname2)

To print the typical detail portion of a standard printfile we use a single subprocedure and line counter:

C        eval   rtncode = print_ps_dtlline(count:fieldname3)
C        add    1           count

3. When a page is complete (using the counter to track this) we call a subprocedure that creates the necessary postscript to end the page and then call the first subprocedure that starts a new page from (1) above. On the last page we pass a parameter to the page end subprocedure that tells it to also put the postscript "trailer" information (which is also in the same postscript "form" file on the IFS).

4. Run a little C module that copies the resulting ASCII IFS file to a USERASCII printfile. This little C module also parses the postscript looking for the %%Page: comment and puts the page number and total number of pages on each page (i.e. "Page: 3 of 13").

5. Send the USERASCII printfile to an appropriate out queue. We set up several outqueues. One that simply prints to a laser printer that supports postscript, and one for each user who wants the results in PDF format. Since we have a linux server for file and print serving, we use lp5250d from the tn5250 project to automatically convert the spooled file to a PDF in each user's home directory. Once they've sent the spooled file to the appropriate out queue, they simply pick up the resulting PDF file via the Network Neighborhood (or My Network Places). From there they can attach it to an email, print it on their inkjet printer, or save it somewhere on their PC as they choose.

James Rich

It's not the software that's free; it's you.
        - billyskank on Groklaw