Posts
this :
Plain text ASCII report (plain.jpg)
into this :
PostScript report (postscript.jpg)
How things work at the moment:
PC's with Windows OS run terminal emulators which connect to Unix/Linux servers. When the ABF application generates a report its output is dumped on disc as a plain text file which is subsequently send to a network or local printer.
When local printing is required (the printer is attached locally to the PC running the emulator) then the emulator opens a direct connection to the local printer port by using special escapes (called transparent ot pass-thru printing) and then forwards the plain text file to it.
In either case the file is forwarded to the printer in RAW format, bypassing any printer drivers and thus is printed as-is. The same process holds also true for reports generated by OpenRoad on Windows
The disadvandes of this approach are :
(1).
although sent in RAW format, the interpretation lies on the printer at hand;
for example some printers cannot translate underlining, may print extra blank
pages etc. Also the iso-8859-7/greek character and font set has to be embedded in the printer and subsequently selected, or it must be installed by using the printer's custom software
The physical size that the report's output occupies on paper is fixed and can only be tweaked by changing the font size on the printer.
So everything is adjusted on the hardware which is cumbersome and not flexible
(2).
Barcodes are output in Code39 format by running reports which have embedded HEX escapes which submit PCL commands to the printer. This requires writing PCL, having a printer understanding PCL (an expensive one) and other drawbacks include : absolute text positioning and limited output space.
(3).
The printed reports look dated/legacy and are not inviting or pleasing to the eye
(4).
I haven’t looked into but I am certain that the new Ingres reporting facilities can produce graphically rich reports but this would require a complete report re-writing/re-designing which is not an option in this case since the amount of reports available supersede 1000 in number
Even if the new reporting facilities were to being used all Ingres sites must be upgraded to a new version and many clients still use old versions even way back to II 2.0;so this is not a universal solution
How can all this be changed ? By calling a2ps to the rescue, or ASCIItoPostScript.
This utility has the ability to take as input a plain text-ASCII file and turn it into a Postscript file.
What are the advantages of that?
Since Postscript is a language (an interpreted one) it handles all printer relating issues internally. It loads the fonts and character encodings on the printer, changes the font-sizes, can use multiple fonts and much more, which makes the process of report generation agile and flexible.
In essence it eradicates all issues brought forward in point (1)
Point (2) now just becomes a simple issue of choosing the right font. No more
embedded PCL commands and escapes inside the report. The font-size and look can be customized.
Code 39 is easier to print than EAN13 though; a string can be directly represented by the Code39 font but EAN13 requires the string/number sequence to be encoded into an intermediate format before it can be represented by the font. a2ps had a small issue in this case and required a small hack into it's character set encoding files to properly generate an EAN13 barcode. In any case the flexibility gains are huge.
As for point (3), a2ps has pretty-printing capabilities which makes the visual outcome in the picture postscript.jpg happen.
These capabilities come in the form of style sheets, postscript prologue files, multiple fonts in the same file, the in-place use of LaTex symbols and most importantly the ability to use regular expressions to do character substitution.
All of these features combined can produce great looking, customizable effects and most importantly allow for a template mechanism which can be automatically applied to any report. For example you can highlight specific parts of the report, use underlining, use Latex/Symbols to denote special conditions or characters etc
However in the most part you are still confined by the characters of the character set/encoding used. This means that the colour lines you see in the transformed report (postscript.jpg) are not possible without some visual trickery.
For example in the Latin1 or ISO-8859-7 or all ASCII extended character sets, there are no graphic/symbol characters at any position. This means that if you wanted to replace the vertical or horizontal bar with something else as to produce the green bars seen here, you can't.
Thus to reach the pretty/green outcome seen here a visual trick has been employed involving regular expressions to replace the characters used for drawing the horizontal and vertical bars (seen in plain.jpg) "|","=","-".
Also,with specially crafted regexes you can replace specific characters or combinations of characters or characters that meet some special criteria giving way to many visual effects.
A2ps’ regexe’s are a bit awkward to use and you also have to understand the a2ps model of how to apply them inside the style sheets.
Other tricks involved in the pretty-printeed report are how to tweak the horizontal line sizes so they weight differently; for example the weights used when underling a header or when underlining/splitting the tabular data are different. All these tricks combined satisfy point (3)
As for point (4) the criteria have been met, as the existent reporting infrastructure was not altered; neither the report code was altered nor an Ingres upgrade was required;the reports continue to work as they used to but now before they get printed they are filtered by a2ps
The additional bonus is that the whole process is truly multiplatform. a2ps works with the same exact settings in Linux, UNIX and Windows/OpenRoad.
However,again,the printer will have to be 'speaking' Postscript. This should not be an issue with laserjets but might be with Inkjets. If the printer does not understand Postscript then Ghostscript can be used as an additional filter which theoretically enables ANY printer to print Postscript and is particularly used in Linux distributions where printer drivers are not easy to find.
Thus by using Ghostrscript any low/cheap inject printer can become Postscript enabled; can even print barcodes on a $60 low end inkjet printer rather than using a $500 high end laser jet.
Another advantage is that a2ps supports both Postscript type 1 and 3 fonts which are vector based and not bitmapped so they scale well. At the same time this is a disadvantage too since those kind of fonts are obsolete and hard to find. Particularly for iso-7 not only the right font should be found but also the iso7.edf encoding description file should be patched.
I hope that in the future a2ps will support Unicode which will :
Switch the regex engine from byte orientation to character orientation
One Unicode font to substitute all fonts which will i18n and enriching reports with graphical glyphs
Getting used to the a2ps environment not particularly easy. You have to get used to style sheets, rules, prologue files, maybe some postscript knowledge is required which would allow one to modify the generated code and sometimes even hack encoding files but it is well worth the effort!
In part 2 we will take a look the setup of the printing architecture with Ghostscript that enables the printing of any report from Unix by using the Windows GDI driver. An extra advandage of using GS is generating the report in PDF format straight from the Unix ABF application; this enables portability, attaching the report to emails, inserting graphics, watermarks etc....
Comments