Ghostscript 8.11 and 8.13 do not produce an ellipse that is closed for the left-hand side figure in the attached eps file. This used to work fine for 8.00 and earlier. (It is not a problem of GSview since 8.00 works fine with a number of different versions of GSview, where as 8.11/8.13 produce erroneous graphs for any of these versions.)
Created attachment 460 [details] Test eps file that shows error when displayed with GSview This is the sample file mentioned in my report.
gs8.11 and CVS HEAD produces same picture as Adobe CPSI, and as Adobe Distiller + Acrobat Reader. gs8.00 produces another image with a closed ellipse, which doesn't comply to Adobe. Maybe it's a bug in gs8.00 . We won't fix 8.00 .
Created attachment 507 [details] EPS file showing error When using GSview and GS 8.14, the upper left panel shows a single ellipse that does not close at the point indicated by arrow. The lower right panel was created parametrically by letting the angle vary through 20*pi. Instead of ten identical overlayed ellipses, this produces a smeared out ellipse. Using GS 8.00, both panels show identical closed ellipses.
I'd like to reopen this bug. There is a definite difference in behavior of earlier versions of GS (pre 8.11) and the later ones. There seems to be a rounding problem in GS 8.14. This is particularly apparent in the lower right panel of the attached EPS file which produces a smeared out ellipse in 8.14.
I should add that the visibility of the break in the single ellipse (upper left example) is resolution dependent. It's visible for resolutions less than 203dpi or more than 497dpi; in between, it's not visible. The smearing of the overlayed ellipses in the lower right panel is noticeable at all resolutions. Perhaps these numbers may help to pinpoint where and how the rounding errors occur.
The attached EPS file doesn't contain a shading. Instead that it fills a polygon. The break appears in the polygon. The bug to be reported to "%%Creator: gnuplot 3.7 patchlevel 3". BTW, the file doesn't satisfy the EPS convention.
I regret to be persistent. Whatever the defects of the eps file created by gnuplot may be, the fact of the matter is simply that the file is displayed differently at different resolutions with 8.14 and it was okay with 8.00. Therefore, unless one can show that it contains explicit code that makes ghostscript do that (and I cannot speak to that since my knowledge of postscript coding is very small), it must be ghostscript that causes this behavior. I would guess it's an accumulation of rounding errors in ghostscript. To play both ends, I have, at your suggestion, also submitted this as a bug to the gnuplot team (https://sourceforge.net/tracker/? func=detail&atid=102055&aid=912888&group_id=2055) and one of the first reactions there also points to rounding errors in ghostscript. Someone posted an awk script that supposedly shows the error (haven't tested it myself).
Let me explain the gnuplot team's view of this problem. As we see it, it's a problem of rounding error pile-up experienced with recent versions of ghostscript if long sequences of relative moves are in a path. In the case at hand, this means an ellipse which used to close implicitly (not by an explicit 'closepath', mind you), now has a gap. And even longer polylines like that 20-turn ellipse will begin to spiral inward or outward. The facts in more detail: *) gnuplot uses its own integer coordinates internally, which are mapped to postscript coordinates by a transformation matrix. *) The polylines being written are pixel-perfect in gnuplot's internal coordinates. *) We optimized gnuplot's PS output for size, by outputting relative moveto / lineto commands if the movement is short, so deltas are shorter than absolute positions. Gnuplot computes these deltas between integer coordinate, so there's no way we can pile up rounding error. *) Starting with some ghostscript version in the 7.* range, ghostscript's internal handling of coordinates appears to have been changed. Since then, rounding errors can be observed to pile up. *) gnuplot was modified to reduce the maximum length of a sequence of relative moves, and will now introduce an absolute moveto every once in a while. But that's a hack at best, not a proper solution. *) IIRC, there must have been at least one other report posted to this bugzilla about this same problem before. I may even have posted it myself.
OK, I've located the earlier bug reports this relates to: #687215 and #687173. See my further comments in ..173, in particular.
Since this bug contains lots of wrong statements, I close it as invalid. 687359 is opened instead.