While on the subject of trying to minimize variations in the way the same GDI printout appears on different printers (i.e. printer independence), I've run across a couple of additional factors that are generally overlooked (including by me):

1. Resolution differences. 300 DPI may seem sufficient for the kinds of line and character spacing precision we are used to with old-fashioned printers (e.g. 10/12 CPI, 6/8 LPI, etc.), but at least as of A-Shell 5.1.1148.0, this is not always the case. The example that brought it to my attention was an invoice that used:

//SETMAPMODE,TWIPS
//SETVMI,180

to set 8 LPI. (180 divides into 1440 exactly 8 times.)

Yet, on one printer it came out perfect, while on another, it was close, but by the bottom of the invoice, the lines were vertically out of position by approximately a whole line, as shown in these two examples:

600 DPI printer


300 DPI printer


And this is on a "form" that is entirely generated by //GDI commands on the fly, so you might think that whatever variations there might be, they would apply consistently across the page.

Taking a ruler to it, I could see that in fact, the lines and boxes and other graphics were identical (except for slight margin differences) between printers, but for the text printing, instead of 8 LPI I was getting something closer to 7.9 LPI. So, what's going on here?

The answer is that A-Shell uses the //SETVMI value to compute the vertical spacing to add for each new line. But since all device coordinates are integer based, the line spacing offset was being rounded down to the nearest integer. And even though 180 TWIPS is, in theory, precisely 1/8", we still have to convert it to a number of pixels. On the printer that was displaying the output correctly, the resolution was 600 DPI, which gives us exactly 75 pixels per line (at 8 LPI). But the other printer was at 300 DPI, which comes out to 37.5 pixels per line, which get rounded down to 37 pixels. In other words, we were losing (or gaining) a half pixel per line, such that by the time we got 74 lines down, it was a full line out of alignment.

The same kind of thing could happen with horizontal spacing, despite the new improvement in precision discussed in the topic Fixed Pitch Precision.

The immediate workaround would be to set your printers to higher resolution if possible.

One particular set of printers where this issue arises frequently is with virtual printers like PDF drivers, which for some historical or other reason, seem to mostly use 300 DPI as their standard resolution. Thus you are more likely to run into the annoying problem just described, where a printout lines up properly on a computer-generated form when using a real printer, but fails to when printing to PDF. In the case of PDF-X, you can go into the printer properties and set the driver resolution from the default of 300 to 600, 1200 or even 2400, which should mostly eliminate that problem. (In most cases, it shouldn't affect the size of the PDF file.)

Another workaround would be to use //TEXTOUT,x,y,... to position every line of text, but that is probably a big change to existing logic.

A better workaround would be for me to revise the spacing calculations so that such rounding errors do not accumulate from one line to the next. But that raises the same kind of issue as discussed in the above-mentioned previous thread: would that be a pure bug fix, or might someone be inadvertently relying on the current logic. (Anyone who is relying on it is probably doomed to pull their hair out eventually, as switching to printers with higher resolution is going to reducing the rounding error causing the spacing to move closer to the ideal.)

But there is another factor which makes virtual printers like PDF drivers different from some real printers, and that is the hardware margin. Most laser printers have a quarter inch hardware margin, reducing the usable page width and length by a half inch. Virtual printer drivers typically have no hardware margin. This mainly affects line spacing that results from setting the LPP in the printer init file, rather than //SETVMI. (For the same number of lines, if the printable page area is taller, the line spacing will be greater.) Many PDF drivers may also have an option to set up a margin (PDF-X does), so if you rely on LPP-based line spacing, you may want to make that adjustment (and hope it stays set).

It's hard to think of a good automatic "fix" for the margin issue, since it is impossible to know when the PDF is generated just what kinds of hardware printers you might want to eventually print to.

This must be why Joe has been pulling his hair out all these years

Again, and if revising the spacing calculation makes it more accurate, I vote for this option but, again, I don't use //setvmi, instead I always use absolute coordinates in TEXTOUT so, do what will satisfy most of our fellows.
(if one day I fall on this problem, surely I will not have too much hair to pull so, even that will not be a problem )

Just to confirm: if you use //TEXTOUT to position each line of text, this fix/change will have no effect on you. So your remaining hair is safe.

Jorge, don't be so hard on yourself, just pull Frank's hair, he probably started this anyway!