Summary: | pswrite produces bad EPS with accumulating vertical shifts | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Cengiz Gunay <cengique> |
Component: | PS Writer | Assignee: | Ken Sharp <ken.sharp> |
Status: | RESOLVED WONTFIX | ||
Severity: | minor | ||
Priority: | P4 | ||
Version: | 8.15 | ||
Hardware: | Other | ||
OS: | Linux | ||
Customer: | Word Size: | --- | |
Attachments: | EPS file that cannot be properly handled by pswrite |
Description
Cengiz Gunay
2008-03-31 16:24:52 UTC
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. |