Bug 12172 - SVG Text does not support subpixel positioning
Summary: SVG Text does not support subpixel positioning
Status: RESOLVED DUPLICATE of bug 40663
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://web.nickshanks.com/browsers/sa...
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-08 16:24 PST by Nicholas Shanks
Modified: 2010-06-17 01:40 PDT (History)
5 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Nicholas Shanks 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.
Comment 1 Nicholas Shanks 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.)
Comment 2 Nicholas Shanks 2007-01-09 05:12:49 PST
Created attachment 12330 [details]
Another (simpler) example from mitz pettel
Comment 3 mitz 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.
Comment 4 Eric Seidel (no email) 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?
Comment 5 Alexey Proskuryakov 2007-02-04 04:24:14 PST
Created attachment 12913 [details]
text-intro-05-t screenshot

Looks correct to me.
Comment 6 mitz 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).
Comment 7 Eric Seidel (no email) 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.
Comment 8 Mark Hubbart 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.
Comment 9 mitz 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).
Comment 10 Nikolas Zimmermann 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 ***