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 — 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.
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.)
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.
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?
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).
This is still an issue. Resize mitz's simple example to see the text bouncing from pixel boundary to pixel boundary.
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).
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 ***