Bug 12172 – SVG Text does not support subpixel positioning

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: SVG

[Nicholas Shanks]

When using the <text> element for more than a single letter, it becomes aparent that Mac OS X's high quality kerning is being ignored and the glyphs are aparently being rendered one at a time on integer pixel boundries (or something like that).

This effect is hardest to read when a bitmap font is used, such as Geneva 9pt &#8212; frequently the letters are either too widly spaced or collide!

It is very noticable when resizing a window such that the dimensions of the image don't change (i.e. it's as tall as the window, and you're making the window wider only). In this instance the whole image is redrawn (another bug, presumably) and the text 'dances' in position, because the glyph boxes fall into new pixels. Contrast this with doing the same to a PDF.

[Nicholas Shanks]

I'm guessing that what you are doing to draw text is to take the outline of each glyph from the font and add it to a compound CG path that is your internal representation of the SVG. Since each text or tspan element is an atomic unit (if there's no :first-letter style), can you not just wait until it's time to rasterise, then ask ATSUI to draw the text for you? That way you get everything done properly (kerning, right-to-left, indic rearrangement, ligature substitution &c.)

[Nicholas Shanks]

Created attachment 12330 [details]
Another (simpler) example from mitz pettel

This is apparently an artifact of rendering to a CGContext that had its CTM translated by a non-integer or scaled, perhaps combined with the "antialiased, integer advances" rendering mode used for screen fonts. One hack that might work is to (temporarily) undo the CGContext transform and apply it to the text-drawing matrix and to the text coordinates. This would work at least for translation, although for scaling it probably wouldn't. Some of the font rendering mode is hiding behind SPIs, so maybe there is a way to use those to get the desired results.

[Eric Seidel (no email)]

Is this bug what is causing the missing ligatures here:
http://www.w3.org/Graphics/SVG/Test/20061213/htmlEmbedHarness/full-text-intro-05-t.html
?  or does that deserve a separate bug?

[Alexey Proskuryakov]

Created attachment 12913 [details]
text-intro-05-t screenshot

Looks correct to me.

(In reply to comment #4)
> Is this bug what is causing the missing ligatures here:
> http://www.w3.org/Graphics/SVG/Test/20061213/htmlEmbedHarness/full-text-intro-05-t.html
> ?  or does that deserve a separate bug?
> 

Probably a manifestation of bug 6626 with your set of fonts. It renders correctly for me (using Geeza Pro instead of the specified font; if you do not have Geeza Pro then you might be falling back to one of the Microsoft fonts that do not shape correctly on the Mac).

[Eric Seidel (no email)]

This is still an issue.  Resize mitz's simple example to see the text bouncing from pixel boundary to pixel boundary.

[Mark Hubbart]

Created attachment 15596 [details]
another testcase

This testcase shows how kerning is affected by this bug at two different point sizes, 1pt and 60 pt, with the 1pt text scaled 60x. Firefox renders the the 60x 1pt text and the 1x 60pt text lines identically for each pair of lines; Safari shows bad kerning on the first pair, and completely overlapping characters on the second. Maybe character widths are computed as integer point values, causing major discrepancies at smaller font sizes.

Comment on attachment 12330 [details]
Another (simpler) example from mitz pettel

<http://trac.webkit.org/changeset/33431> fixed this case (for Windows and Leopard).

[Nikolas Zimmermann]

40663 will fix this bug, _finally_! Just took us some years ;-)
The exciting thing is that most W3C testcases, now look pixel perfect to our rendering in terms of text.

*** This bug has been marked as a duplicate of bug 40663 ***