Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!hp4nl!ruuinf!piet
From: piet@ruuinf (Piet van Oostrum)
Newsgroups: comp.lang.postscript
Subject: Re: Postscript Bug
Message-ID: <1180@ruuinf.UUCP>
Date: 8 Mar 89 12:36:53 GMT
References: <4571@umd5.umd.edu> <577@adobe.UUCP>
Sender: piet@ruuinf.UUCP
Reply-To: piet@ruuinf (Piet van Oostrum)
Organization: Dept of Computer Science, University of Utrecht, Holland
Lines: 58
In-reply-to: greid@adobe.com (Glenn Reid)

In article <577@adobe.UUCP>, greid@adobe (Glenn Reid) writes:
 `
 `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.
 `

If the operations are done in floating point (as I assume they are), why
would you lose so much accuracy? Or is another representation used? If so,
what are the rules to use when you don't want to get problems?

 `I haven't been able to determine from either example exactly where the
 `roundoff is happening, but it's in there somewhere.
 `
Would you mind looking into it to show where it is. I don't see it!

 `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.
 `
I tried this and it did not help.
I would ask you, PLEASE investigate the possibility of a bug being present.
The fact in both examples that one coordinate that has the same value in
two cases gets positioned different would indicate that it is not a pure
rounding problem. Moreover, in my example (Message-ID: <1166@ruuinf.UUCP>)
the result is correct if I don't use the 'setcachedevice' operator,
suggesting something in the cacheing mechanism. Would you mind looking into
this, as I fail to understand how the caching should give rounding
problems.

 `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.
 `
But if you must be aware of rounding problems, what does
device-independence mean?

 `I hope this helps.
 `
It didn't and I hope Adobe will be a little bit more helpful.

 `Glenn Reid
 `Adobe Systems
 `PostScript Developer Tools & Strategies
-- 
Piet van Oostrum, Dept of Computer Science, University of Utrecht
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands
Telephone: +31-30-531806. piet@cs.ruu.nl (mcvax!hp4nl!ruuinf!piet)