ppmraw -r72 298-09.ps, the box 298-11. ppmraw -r300 298-09.ps, the box 298-11. The line width appears too big. Reported by Julia as a regression from Dec 09, 2003. Reproduced by Igor with today's CVS HEAD, compared with CPSI.
Same with 321-09.ps .
ppmraw -r300 CAT_LOGO.ps - a line width is bigger, but with a Type 1 stroked font (maybe another problem).
With 298-09.ps, it looks as it performs 'fill' instead 'stroke', because the circle doesn't become wider even with 1200dpi. With -dNOCACHE the rendering is good. Note that without -dNOCASCHE some characters paint good - those ones, which look too big for caching.
Well, it appears a flattening problem. The new revision, performing a strokepath with cache device, generates too many segments for 'arc'. Therefore stroking it got something like a 'fill'. The number of segments can be viewed with inserting "false upath length ==" into the charproc.
Well, it happened because we removed "point_near" filters from gx_flattened_iterator.
Rendering to cache, it passes flatness=0 and the number of segments appear 4 times smaller. Therefore the result is different with -dNOCACHE. But I wonder why the December 09 revision generates SAME path as the current one with - dNOCACHE : probably this happens due to the flattened path is a symmetric 2^k- gon, so old filters remove exactly those segments, which the new one doesn't generate with -dNOCACHE.
I don't like that gx_fill_path, gx_stroke_fill and gx_stroke_add uses zero flattness when rendering to cache device. IMO it is reasonable with Type 1,2,9,11,42 fonts, but it must not happen with Type 3, 10 fonts.
A part of Comment #6 appears incorrect : the December 09 revision generates same path as the current one with -dNOCACHE, but with no -dNOCACHE parths are different. So no wonder.
Renamed the bug because the old title is misleading.
Patch http://www.ghostscript.com/pipermail/gs-cvs/2004-September/004800.html
The comment #2 is moved to Bug 687667.