[gs-devel] What winding rule does Adobe implement for Type1? (SF #539359)
raph at casper.ghostscript.com
Thu Apr 25 22:53:16 PDT 2002
In playing around with the winding rules, I've discovered that Adobe
seems to implement both eofill and fill, and the choice is made
somewhat nondeterministically. You can see this when you change
sizes, both with the EURO0.PDF test file, and with my winding.pdf,
hand-drawn to abuse the winding numbers in Type1 fonts. This is true
for AR4/Linux and AR4/Windows. A screenshot that Igor sent me that is
named euro-AR4.05c.bmp, but appears to be from AR5/Win, also displays
fill rendering at a largish scale factor.
In AR4/Linux, EURO0.PDF appears to be drawn with fill at 25% and up,
and eofill at 12.5% and below. winding.pdf appears to be drawn with
fill at 150% and up, and eofill at 125% and below. The glyph size is
considerably smaller in the latter, so these results are consistent
with the decision being made based on glyph size in device units.
Based on this finding, I'm comfortable with the following course of
action: use the regression tools to compare HEAD-with-eofill against
HEAD-with-fill, to discover whether there are any fonts that depend on
eofill for correct rendering. If not, retain the current patch which
switches to fill for all Type1 rendering, change the resolution on bug
#539359 from "Remind" to "Fixed" (status is already "Closed"), and
advance the baselines in the nightly regressions.
At least then our rendering would be consistent, unlike Adobe's.
BTW, I have seen other instances of TT fonts converted to Type1, and
rendering incorrectly with the eofill rule. Among these are PostScript
documents containing PMINGLIU.TTF converted to PDF by Adobe Acrobat
Thanks to Russell for discovering the scale-dependent behavior in AR4,
and for producing AR4/Win screenshots. The relevant files can be found
More information about the gs-devel