Bug 12172

Summary: SVG Text does not support subpixel positioning
Product: WebKit Reporter: Nicholas Shanks <nickshanks>
Component: SVGAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: krit, marcus.erronius, mitz, oliver, zimmermann
Priority: P2    
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
URL: http://web.nickshanks.com/browsers/safari/svg-text.html
Attachments:
Description Flags
Another (simpler) example from mitz pettel
none
text-intro-05-t screenshot
none
another testcase none

Nicholas Shanks
Reported 2007-01-08 16:24:45 PST
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.
Attachments
Another (simpler) example from mitz pettel (481 bytes, image/svg+xml)
2007-01-09 05:12 PST, Nicholas Shanks 		no flags
Details
text-intro-05-t screenshot (43.69 KB, image/png)
2007-02-04 04:24 PST, Alexey Proskuryakov 		no flags
Details
another testcase (800 bytes, image/svg+xml)
2007-07-20 02:24 PDT, Mark Hubbart 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Nicholas Shanks
Comment 1 2007-01-09 03:51:17 PST
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
Comment 2 2007-01-09 05:12:49 PST
Created attachment 12330 [details] Another (simpler) example from mitz pettel
mitz
Comment 3 2007-01-09 07:27:32 PST
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)
Comment 4 2007-02-04 04:10:54 PST
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
Comment 5 2007-02-04 04:24:14 PST
Created attachment 12913 [details] text-intro-05-t screenshot Looks correct to me.
mitz
Comment 6 2007-02-04 04:55:49 PST
(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)
Comment 7 2007-06-12 09:45:45 PDT
This is still an issue. Resize mitz's simple example to see the text bouncing from pixel boundary to pixel boundary.
Mark Hubbart
Comment 8 2007-07-20 02:24:23 PDT
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.
mitz
Comment 9 2008-05-13 22:19:28 PDT
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
Comment 10 2010-06-17 01:40:14 PDT
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 ***
Note You need to log in before you can comment on or make changes to this bug.