On "/back/wards" compatibility's implications...
[something I'm using for a super-duper demonstration, I'll discuss later]
Imagine this scenario: back in the dot-matrix era, printing graphics was a big task, even at 120x120dpi, an 8in x 10in page would've required rendering a 1.2 Mega Pixel image. Computers of the era didn't have memory for that!
Printers of the era had fonts stored in the printer's ROM, and used a technique similar to Sprites [in videogames]--and similar to MDA/CGA video-cards' text-mode--to render and print each, say, 12dot x 12dot text character.
So, imagine printing a document with an image, captioned, and text surrounding it.
Printers of the era would first print all that text [fast, low memory requirements], then go /back/ [note that word] and print the memory/bandwidth-intensive graphic.
Why my harping on /back/?
Because it means that the paper can be fed *both* ways, and, with that, printing can basically occur in any order on the page one might desire.
Now that boring "raster" line-by-line printing can get a whole lot more interesting to watch.
Again, a ton of thoughts [and a few implementations] on what to do with this...
Another issue [opportunity] arose when my 20+y/o ink cartridge lost control of its top 8 nozzles [and several others interspersed]. No, I don't think they're clogged; this printer handles its 64 nozzles, physically-arranged in a line, electrically as 8 rows and 8 columns. It seems "Column 1" has burnt out [as well as "Segment 5" and 8, as I recall. Though a missing pixel surrounded by 6 that work, at 360dpi, is hardly noticeable]. But, losing 8/360ths of an inch, well that's noticeable. In text-mode, with the default font, that's the top bar in a 'T', which is difficult to read. In graphics mode, though, especially, say, when printing a datasheet, it makes pinouts quite difficult to read.
I've, thus, modified the ghostscript driver to account for the missing pixels, and now I can print datasheets and even grayscale full-page photographs!