| Summary: | line misalignment with respect to points in 8.11 but not 8.00 | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Stephen Harker <Stephen.Harker> |
| Component: | PS Interpreter | Assignee: | Jack Moffitt <jack> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | broeker |
| Priority: | P2 | ||
| Version: | 8.11 | ||
| Hardware: | Macintosh | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: | test postscript file | ||
|
Description
Stephen Harker
2003-11-26 20:28:05 UTC
Created attachment 384 [details]
test postscript file
This postscript graph exhibits a misalignment in lines with respect
to points with gs 8.11 but not 8.00 or 7.05 on my ppc linux system.
Ghostscript uses fixed point repressntation of the device coordinates.
So there is a trade-off between the range and precission.
File gxfixed.h was changed on 2003/02/15 22:37:01 to have 8 bit precission.
The previous 12 bits was too large to accomodate large format inkjet printers
at modern resolutions of 720 and 1200 dpi.
The long chain of rlineto operations in the source file accumulates
roniding errors, which becomes visible at the end of the line.
There are several ways to improve the precission.
(1) Use to 64-bit fixed numbers. This is very easy to do but may affect the
performance.
(2) Keep current point calculations in float point. Most precission problems
are caused by inprecise current point calculations.
(3) Replace all fixed arithmetic with floating pont one. This can improve
the performance on some platforms.
One can also work around the problem by:
(1) compiling a private version of GS with higher precission and lower range.
(2) fixing the PS file using UNIX text tools.
*** Bug 687215 has been marked as a duplicate of this bug. *** I think the more important point is not whether the currentpoint is kept in floating point or fixed point, but rather whether it's kept in abstract coordinates (what you pass to (r)lineto) or in device coordinates. The surprise in this particular case was that all the movetos and linetos in the gnuplot-generated output are, in fact, integers, so round-off problems were never anticipated. The problem occurs because each integer-valued rlineto and rmoveto gets transformed to non-integer vectors in device coordinates. Adding those together accumulates round-off, and transforming that back in the 'currentpoint' operation suddenly gets us non-integer coordinates for the following moveto. We're reluctant to completely let go of relative moves and lines --- we use them because a lot of the lines we output are, indeed, very many-segmented polylines, where use of relative moves gains us quite an advantage in output size. |