Cross-platform printing

Rob Fitzpatrick

Rob Fitzpatrick

ProgressTalk.com Sponsor
We have a cross-platform application (ABL CHUI) that, among other things, prints various reports and correspondence. The print jobs use a variety of orientations, character and line densities, bold, underline, etc. The current approach is to printing is to define printers in the DB, and for each, to define the various PCL 4/5e/6 control codes that achieve these effects without having to hard-code them. The code then streams the combination of control code field values and business data to the printer to produce the finished print job. I hope that makes sense.

What I'm looking for is a general sense of how people in the Progress development community are doing printing from ABL these days. A platform-agnostic approach would be preferable, but even something *NIX-specific would be beneficial. Do you send raw data/codes straight to the printer, or is that an antiquated approach? Do you use frameworks like BIRT? Do you create PDFs and send them to a printer/print server that understands how to handle them?
 
We used to send raw PCL-style codes on occasion, but nowadays we do 2 things:

1. Output simple ASCII using DISPLAY statements, etc., and no special fonts or formatting;

2. Output complex (sometimes IMO *really* complex) PostScript using a combination of macros pre-coded into files that we concatenate at run time, and statements like 'PUT UNFORM x' where 'x' contains some PostScript code that we build up at runtime in P4GL.

We don't use any utilities for this (well we do have one for the purposes of managing forms, but that's a different matter really), and we don't do any PDF directly. Maybe we should, I dunno.

Not sure if you care about this part, but our process for getting these reports out to users of WebClient is quite involved and honestly, every time I see something actually print, I am amazed that it all works. We have a whole infrastructure that takes ASCII files, turns them into PS, then into PDF, which then gets streamed out thru an AppServer into Acrobat, etc. etc. We also have a fairly involved process for sending files out to print vendors, which is very important to us (and important that it be reliable).

At the end of the day it all works pretty well, we have some pretty spiffy looking output, and our servers don't need to know about all the printers spread across the country, and said printers don't need to be PS capable (so pretty much any printer works). On the downside, we have a lot of unwholesomely PostScript specific code in our P4GL ... but, if I ranked our problems from 1 to 100, that would be down around 100 somewhere.
 
I'm not sure if that remark is directed to the OP, or my reply. In any case;

1. Indeed, the code I am referring to has been around since (the good old) Bill Clinton days.

2. We convert PS to PDF server-side using a batch FOSS utility, so we definitely use PDF, just not on the P4GL end of things. I don't know either very well, but I know PS is Turing complete (not so sure about PDF), therefore useful for complex documents with lots of conditional logic etc.; but it (PS) is not amenable to sending out to random printers of unknown origin.

3. I'm not sure what DOC means.
 
Rob,

Our legacy code did exactly what you did, with printers defined in the db with the appropriate PCL to send escape codes. Note that we work strictly on various flavors of Linux and *nix.

A few years ago, though, I wrote a front end to pdfinclude that works extremely well for us, and have added additional functionality to that over time.

The front end is passed a text file created from either legacy code or any of our new code, along with additional parameters (pdf file name, various options such as default font name/size to use and/or load, , margins, portrait/landscape, etc etc), printer and/or email, and an optional configuration file name.

The configuration file is a template for the form and contains things like logos/pictures, fixed text, lines, boxes, graphics, watermarks, and the like.

If all we need to do is create a text pdf without any special handling, no configuration file is necessary.

For things like invoices, statements, checks, etc, the configuration file is able to create the form layout, then we only need to pass the text file and merge the two to generate the pdf.

We have options in the front end to allow us change fonts dynamically, colors, html like processing (in the latest version of pdf include), use multiple configuration files, place barcodes, and so on.

Printing is dependent on the printer, either you can pass the pdf directly or we run it through pdf2ps (part of ghostscript) before printing.

Using this has allowed us to prototype complex forms rapidly without having to do much mucking about in the standard Progress coding.

Not trying to sell you on this method, but it may be an approach to look into. Feel free to contact me if you want some more on this.

Larry
 
Rob Fitzpatrick said:
Do you use frameworks like BIRT?
Click to expand...

some of us do that, I for one have to confess having a graphical report designer pleases me more that going blindly and do the 'design' inside the abl code but that's just me being lazy or getting old :)
well, in fact I can focus on getting the data and let a designer handle all the fancy formatting the end-users requests for... and most of the time the data is already there if we can re-use the application business logic.

if care to explore that path you can find some information here http://www.ganimede.ro/cms/products/abl-report/ and http://www.ganimede.ro/cms/products/abl-jdbc/overview/

you can of course contact me directly if need more details or can attend the presentation I'll have on the subject at upcoming PUG Challenge EMEA in November http://www.pugchallenge.eu/index.ph...ry&layout=blog&id=28&Itemid=165&limitstart=20
 
You must log in or register to reply here.
Back
Top