The system I am using is a iBook (700Mhz G3) running YellowDog Linux 3.0. I have found many graphs that have been generated using R (http://www.cran.r-project.org/) with lines and points which are aligned when viewed under gs 8.00 show lines and points which, while aligned on the left, become more misaligned as the x-coordinate increases and most severe on the right hand side. This can be easily shown in a relatively small 44 kb postscript file. These plots can be viewed in both gs 8.00 and 8.11 at the same time with one appearing aligned and the other misaligned.
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.
*** This bug has been marked as a duplicate of 687359 ***