The answer to the question posed rhetorically in my previous post is that Window’s overcomplicated printing system is what lies between Adobe’s SVG viewer and Adobe’s PostScript interpreter in my printer.
The API of
Microsoft Windows is horribly complicated by the fact that most
of what they knew about graphics they learned from writing
Microsoft Word. They decided that printing should be just the
same as rendering to the screen (because that’s what Word
needed), and as a result the GDI layer is stuffed full of
second-guessing and really, really obscure features. This is
where the distinction between ‘device’ and
‘logical’ pixels comes in. It also explains why
when you implement an OLE custom control, the first thing you
have to do is write a Paint method that does all
sorts of hairy calculations to translate the fictional
paper-based coordinate system in to actual screen pixels. Even
when your custom control is a pushbutton or (as it was when I
was doing this) an interactive, scrolling map. In order to
allegedly make it easy to print documents, the graphics system
has had extra features added, which means it is more complex,
and so buggier and harder to use.
If your response to this is that this system is how web pages can be printed, I refer you to my previous post, in which we discover that all this mess did not make it possible to print SVG merely by pretending a printer is the same as a screen.
Anyway, as a Linux user, I have an alternative: convert my graphics to PostScript and send it direct to the printer via the printer queue. This is less crazy that is sounds, but only because I have done enough PostScript programming in the past that I know a way to about it. I also have a ten-year-old copy PostScript Language Reference Manual 2/e (the red book I alluded to earlier), an excellent guide to the PostScript Level 2 language, as understood by my printer.
For the files in question (300-dpi, colour GIFs), it makes sense to try to reduce size of the image data in the PostScript document. My current attempt goes like this:
- convert to greyscale (my printer is monochrome anyway);
- reduce the greyscale range to 0..15 (these pictures only use two shades of grey), and so squeeze two samples per byte;
- run-length encoding, to collapse long lines of the same colour;
- use ASCII85Encode rather than ASCIIHexEncode to convert the bytes to text (×1.25 expansion rather than ×2).
As a result in a sample page I get the following ratios (with the size of the GIF files added for comparison):
| Pixels | Characters | Pixels/Character | GIF size |
|---|---|---|---|
| 718,662 | 168,580 | 4·26 | 77,668 |
| 724,446 | 187,171 | 3·87 | 79,922 |
| 724,446 | 124,088 | 5·84 | 58,750 |
| 541,926 | 137,209 | 3·95 | 67,983 |
| 541,926 | 87,532 | 6·19 | 43,859 |
The PostScript is 694 KB (compressed 435 KB), which compares well with the 2553 KB of the PDF version of a similar page, though not so well with the 332 KB of the SVG version. I could probably risk using binary data rather than one of the ASCII encodings and reduce the size of my PostScript data by almost 20%.