[Webkit-unassigned] [Bug 60317] Text is scaled in a stair-step pattern

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=60317





--- Comment #13 from Nikolas Zimmermann <zimmermann at kde.org>  2011-05-19 00:47:43 PST ---
(In reply to comment #12)
> I managed to get the attached test case working properly by scaling the specified Font and not requesting the closest matching one. I ran into a snag when running the regression tests with this change because various SVG tests pick extremely small fonts and scale them up by 50x or more. The font engine throws out fonts that are too small to render, and we end up not displaying anything...
> 
> I feel like I'm back to square one. Ideally we could pick the closest font and scale it by the delta between what was provided and what was requested, but I still don't know how to figure out what the *actual* size CGFont we were given is! Any ideas?

Hmm, I'm not sure I follow. For SVG we recently changed the way we request fonts. Before we always used the actual specified font size:
<svg viewBox="0 0 5 5">
<text font-size="1" y="1">A</text>
</svg>

So we requested a font with size 1, and then just rendered it on the context, praying for the graphics engine to handle it correctly. What we do now, is calculate the scaling factor, to get the real font size that will appear on the screen (eg. here sth. like 40, if the width/height of the browser window is large enough). Then we scale the current context by the inverse scaling factor, render the text, and scale back.
This way we get antialiasing and hinting working correctly in arbitary transformed documents.

Okay, I think I should be more concrete:
Say we have a document with width=1000, height=1000. Then the <svg> from the example above is scaled to fit in that document. The text appears at y=200, and has a font size of 200.

When painting, the RenderSVGRoot object scales the content by 200, then the font is rendered using font size 200, to do that we scale the context by 1/200, draw the font with size=200, and scale again.
Obviously only text needs this trick, any Path can be arbitary transformed, w/o loosing precision....

I hope that explains what SVG is doing ..... though the bug you've found is still valid, but has nothing to do with that part of the SVG text handling.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.