Skip to main content

Transforming Ingres' legacy reports with PostScript (Part 1)


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

Popular posts from this blog

Book Review : How To Create Pragmatic, Lightweight Languages

At last, a guide that makes creating a language with its associated baggage of lexers, parsers and compilers, accessible to mere mortals, rather to a group of a few hardcore eclectics as it stood until now.

The first thing that catches the eye, is the subtitle:

The unix philosophy applied to language design, for GPLs and DSLs"
What is meant by "unix philosophy" ?. It's taking simple, high quality components and combining them together in smart ways to obtain a complex result; the exact approach the book adopts.
I'm getting ahead here, but a first sample of this philosophy becomes apparent at the beginnings of Chapter 5 where the Parser treats and calls the Lexer like  unix's pipes as in lexer|parser. Until the end of the book, this pipeline is going to become larger, like a chain, due to the amount of components that end up interacting together.

The book opens by putting things into perspective in Chapter 1: Motivation: why do you want to build lan…

How Much Gameplay Can You Pack In Just 13K?

Given our expectations of Xbox games, you might consider writing a game within a 13K limit, which is the challenge for the annual js13K competition far too restrictive. Its results are now out and prove that it is possible to produce a game that is fun to play. 

Back in the tape loading days and on platforms the likes of Commodore64 games came in sizes of 4K or less. As proof of concept, here's a list of a few such 4K titles, copied over from Lemon64 's archive:
Alien SidestepBug CrusherDot GobblerClose EncountersDot Gobbler v2GridrunnerLaser CyclesMarios BrewerySpace ActionSpace RicoshayTank WarsHesmon64Retro Ball  Fast forward to now, at a time when Javascript's eating the world by making all sorts of applications or  games available to everyone through the medium of the browser, rendering the need of dedicated platforms and Operating systems obsolete, 13K is sufficient enough to pack both gameplay AND cool graphics due to the advanced browser engines and HTML5.

Hour of Code 2017 Introduces App Lab

t's the time of year when the world-class Hour of Code once more commences; just an hour for introducing coding to the uninitiated, having them complete self guided tutorials. But is a hour sufficient? What can a beginner actually code within this limit? The answer is a bit more complicated than that, so let's find out all about it! Integrated into the larger, worldwide, annual Computer Science Education week, this year taking place December 4-10, Hour of Code's novel mission has always been to get everybody coding, aged from 4 to 104, by providing: "a one-hour introduction to computer science, designed to demystify code, showing that anybody can learn the basics, and broadening participation in the field of computer science". But first of all, why this obsession with Computer Science, in particular in getting  kids as young as 4 to learn to code? The answer is simple. Nowadays code is everywhere around us, from desktop computers to mobile phones and, thanks to w…