Content-Type: text/shitpost

I spent two hours today figuring out why the margins were chopped off this thing I was printing. It was a long diff file, and I was trying to print it with a2ps. Usually a2ps is pretty nice; it lets you print plain text files in various formats, and I use it often. But a diff file where the leftmost two columns are cut off is useless, because the leftmost two columns are the most important part of a diff file.

First I wasted a lot of time tinkering with the CUPS PPD file for the printer. It has a lot of stuff that looks like this:

*PageSize Letter/Letter 8.5x11in: "<</cupsInteger0 2/PageSize[612*792]/ImagingBBox null>>setpagedevice"
*PageRegion Letter/Letter 8.5x11in: "<</cupsInteger0 2/PageSize[612*792]/ImagingBBox null>>setpagedevice"
*ImageableArea Letter/Letter 8.5x11in: "18 36 594 783"
*PaperDimension Letter/Letter 8.5x11in: "612 792"

and it's not real clear how these things are related or which of these 10 numbers needs to be changed. Okay, the printer was only cutting off the two short edges, not the two long ones, so we can rule out half the numbers that refer to width dimensions rather than length ones. And tinkering with the first two lines didn't change the output at all (what are they for, anyway?) so really there are only three numbers to play around with: the 36, the 783, and the 792.

I messed around with those and printed 26 test pages with the same content in 26 slightly different positions, labeled each one with the magic numbers that produced it and tried to develop a theory about what the numbers actually meant. And I did develop a good model and I thought I understood more or less what they were doing, except that it didn't solve my problem because the content was somehow cut off in every single one of those 26 pages.

That 26 doesn't count the three times I choked the printer by trying to supply negative values in place of the 36.

One complication was that there is at least two ways for the content to be cut off. It could be cut off because CUPS thought it would be outside the printable area, and so didn't bother to render it there, or it could be cut off because it was outside the printable area, and so even though CUPS rendered it, the printer couldn't put any ink there. If the cutoff is far enough from the actual paper edge, you can be sure it was the first thing and not the second, but that is no help because what you really want to know is what is going on when the cutoff is near the edge.

At last by comparing the standard system test page and the printed output of a2ps I realized that part of the problem was that a2ps was cutting off the margin even before it got to the printer driver. And then I did track down the problem. a2ps uses this library called libpaper to decide how big your paper is so it can decide how to lay out the page. If you don't specify a paper size, it defaults to whatever is in /etc/papersize if that exists…

But if there isn't one it defaults to A4 size because the original author of a2ps lived in some A4 paradise, and…

No, that wasn't it. That would have cut off the long sides, not the short sides, because A4 is longer and narrower than US letter. And anyway, /etc/papersize did exist and specified letter. No, the actual reason is even dumber than that.

I was printing on a Hewlett-Packard Deskjet D4360. And apparently letter-size paper somehow becomes different when it is inserted into a Hewlett-Packard Deskjet. It is no longer letter paper. It transforms, magically, into letterdj paper. When I ran a2ps --media=letterdj, or when I put letterdj into /etc/papersize, everything came out whole, even the leftmost two columns of text.

And that's what I did with a small but appreciable fraction of my ever-diminishing remaining lifetime.