Overlapping glyph parts don't get filled

[Kjoonlee-users]

When rendering a Text object with a font glyph that overlaps itself (such as the capital A and Q characters in the "Summersby" font), Inkscape will always render the self-overlapping characters with the 'evenodd' fill rule where overlapping parts do not get filled in, regardless of the text content element's fill-rule property (whose initial value is specified in the SVG standard as 'nonzero', where all parts are filled in regardless of overlap).

Only if the text object is converted to a shape using Object To Path will Inkscape correctly respect the fill-rule attribute, even though the SVG Standard lists fill-rule as applying to both shapes and text content elements.

SVG Standard: fill-rule
http://www.w3.org/TR/SVG11/painting.html#FillRuleProperty

Font: Summersby
http://packages.debian.org/summersby
http://ftp.debian.org/debian/pool/main/t/ttf-summersby/ttf-summersby_1.007.orig.tar.gz

Test case:
http://blacksun.ivyro.net/img/summersby.svg

Inkscape's rendering:
http://blacksun.ivyro.net/img/summersby.png

Importance:
This affects ttf-unfonts, the leading Free Software font in the Korean language.

Tested with:
Inkscape 0.48.0 and 0.48+devel r9906 on OS X 10.5.8
Inkscape 0.47 on Mac OS X 10.5.8
Inkscape 0.47pre4 on Windows 7, AMD64
Inkscape 0.45.1 on Windows XP, i386
Inkscape 0.44 on Knoppix 5.1 DVD, AMD64

[Kyungjoon Lee (kjoonlee)]

Could the importance be changed from low?

This affects ttf-unfonts, the leading Free Software font in the Korean language.

[nightrow (jb-benoit)]

This bug seems old, bumping up the importance to get some dev attention.

[Luca Bruno (lucab)]

Can you confirm if it happens even with 0.46?

[Kyungjoon Lee (kjoonlee)]

Yes, happens with 0.45 for Debian and 0.46 for Windows.

[Kyungjoon Lee (kjoonlee)]

Bump. I read somewhere that glyph components should receive nonzero filling.

[su_v (suv-lp)]

See duplicate bug #595355 for more recent examples; bug still present in Inkscape 0.48.0 and current trunk (0.48+devel r9906).

[Stuart P. Bentley (stuart)]

bug #595355 also describes the full justification from standards (http://www.w3.org/TR/SVG11/painting.html#FillRuleProperty): in short, the fill-rule property applies to text content elements, and the initial value for fill-rule is non-zero.

While an across-the-board change to non-zero would be closer to correct than the current behavior, the standard-compliant fix would be to respect the fill-rule property when rendering a text content element, using even-odd if that value is set and non-zero otherwise.

[su_v (suv-lp)]

No longer reproduced with current trunk (tested with 0.48+devel r10795 and latest r13144 on OS X 10.7.5): fill-rule applied to text objects is now respected; if fill rule is not specified explicitly, the text renders with fill rule 'nonzero'.

[su_v (suv-lp)]

Fixed with the merge of the cairo-rendering branch in r10326.
(reproduced with r10325, not reproduced with r10326)