Article View: comp.lang.postscript
Article #8087Re: Postscript Bug
From: Piet van Oostrum
Date: Wed, 08 Mar 1989 12:36
Date: Wed, 08 Mar 1989 12:36
58 lines
3125 bytes
3125 bytes
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)
Technical Details
Message-ID:
<1180@ruuinf.UUCP>Path:
arc1-ca.pugleaf.net!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!pietReferences:
<4571@umd5.umd.edu> <577@adobe.UUCP>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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)