🚀 go-pugleaf

In article <4571@umd5.umd.edu> butt@umd5.umd.edu (Edgar Butt) writes:
>I have found a bizarre bug in Postscript 47.0 on a Laserwriter II NT.
>Is this a known bug?  Is there is a rom update available from Apple?
>Does it occur on other printers or versions?
>
...
>Below is a short Postscript program to illustrate the problem.
>It generates eight pairs of joined vertical line segments.
>The leftmost four pairs are out of alignment by one pixel, the rest
>are not.  The bottom eight line segments are all 88 pixels high.
>The top line segments vary from 73 to 80 pixels high.  Between 76 and
>77 pixels, the horizontal alignment changes.

Both this message and one following it (to do with bitmap fonts)
mentioned "bugs" in PostScript printers because output was off by a
pixel somewhere.

Both of these effects are due to numerical methods.  In each, the scale
factor was essentially 1/resolution, which loses much of the accuracy
of the numeric operations.

I haven't been able to determine from either example exactly where the
roundoff is happening, but it's in there somewhere.

Another useful way to avoid round-off problems in position on an
integer grid is to redefine the "moveto" operator (and possibly also
the "lineto" and other path construction operators) like this:

    /moveto { transform round exch round exch itransform moveto } bind def

This will make sure that the position is aligned with a pixel boundary
before the imaging takes place, minimizing one-pixel errors.

Remember that the PostScript language coordinate system is an "ideal",
and is device-independent.  The same program can run on printers of
arbitrary resolution, and if you try too hard to tailor it to a bitmap
grid, you often get undesirable results.

I hope this helps.

Glenn Reid
Adobe Systems
PostScript Developer Tools & Strategies