For the attached EPS file, the pswrite device produces accumulating vertical shifts in lines even though gs can properly display the file with the x11 device. To reproduce: $ gv broken.eps $ eps2eps broken.eps gs-out.eps $ gv gs-out.eps The two images on the screen should differ if superposed. System: openSUSE 10.3 (X86-64), kernel 2.6.22.12 GS: ESP Ghostscript 8.15 (2006-04-19)
Created attachment 3908 [details] EPS file that cannot be properly handled by pswrite The file was originally produced by OpenOffice "Save as EPS" option from a Metafile object.
The effect is small but obvious when the source and result files are compared against each other. ESP Ghostscript is an obsolete, unofficial fork but the problem also exists in the current development version. The bug is caused by deliberate reduction of output precision to save the file size. Commenting out this misfeature fixes the problem at the cost of 1.5 times larger output file. /* * We redefine path tracing to use a compact form for polygons; also, * we only need to write coordinates with 2 decimals of precision, * since this is 10 times more precise than any existing output device. */ static inline double round_coord2(floatp v) { return v; // floor(v * 100 + 0.5) / 100.0; } There's another approach - track the error between the precise and rounded position and adjust relative movements to keep the error within the selected precision.
Alex didn't say what file the patch goes in, but I think it is src/gdevps.c
pswrite is effectively unsupported, but the supplied patch may be used to resolve the problem. We intend to carry on developing ps2write in the future as the replacement for pswrite.