Bug 687582

Summary: Flatness in a Type 3 font
Product: Ghostscript Reporter: Igor Melichev <igor.melichev>
Component: Graphics LibraryAssignee: Igor Melichev <igor.melichev>
Status: NOTIFIED FIXED    
Severity: normal    
Priority: P3    
Version: master   
Hardware: PC   
OS: Windows XP   
Customer: Word Size: ---

Description Igor Melichev 2004-07-21 05:55:47 UTC 
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.
Comment 1 Igor Melichev 2004-07-21 06:00:44 UTC 
Same with 321-09.ps .
Comment 2 Igor Melichev 2004-07-21 07:18:28 UTC 
ppmraw -r300 CAT_LOGO.ps - a line width is bigger, but with a Type 1 stroked 
font (maybe another problem).
Comment 3 Igor Melichev 2004-09-09 11:16:31 UTC 
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.
Comment 4 Igor Melichev 2004-09-09 11:49:11 UTC 
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.
Comment 5 Igor Melichev 2004-09-09 12:04:53 UTC 
Well, it happened because we removed "point_near" filters from 
gx_flattened_iterator.
Comment 6 Igor Melichev 2004-09-09 12:36:54 UTC 
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.
Comment 7 Igor Melichev 2004-09-09 12:47:30 UTC 
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.
Comment 8 Igor Melichev 2004-09-09 13:08:07 UTC 
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.
Comment 9 Igor Melichev 2004-09-09 13:45:06 UTC 
Renamed the bug because the old title is misleading.
Comment 11 Igor Melichev 2004-09-09 14:08:23 UTC 
The comment #2 is moved to Bug 687667.