Bug 59589 – REGRESSION(r77282-r77559): Scaled SVG text should pixel-align pre-scale

• Status: UNCONFIRMED
• Component: SVG

[Alan Tam]

Created attachment 91256 [details]
test case

See the attached test case.

<svg:g transform="scale(0.01)">
    <svg:text x="0" y="2000" style="font-size: 1100px; font-family: Georgia;">
        iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
    </svg:text>
 </svg:g>
 
The code above should draw "i" glyphs pixel aligned when they are 1100px large and then scaled down to 1/100 of its size.
WebKit r77559 later draw them pixel-aligned as if they are 11px large (i.e. after scaled down 1/100).

[Dirk Schulze]

(In reply to comment #0)
> Created an attachment (id=91256) [details]
> test case
> 
> See the attached test case.
> 
> <svg:g transform="scale(0.01)">
>     <svg:text x="0" y="2000" style="font-size: 1100px; font-family: Georgia;">
>         iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
>     </svg:text>
>  </svg:g>
> 
> The code above should draw "i" glyphs pixel aligned when they are 1100px large and then scaled down to 1/100 of its size.
> WebKit r77559 later draw them pixel-aligned as if they are 11px large (i.e. after scaled down 1/100).

Scale is like zooming, this of course influences the kerning as well. If I understand you right, you want to have the distances between the letters independent of the scaling? Nevertheless, the current behavior is exactly how it should look like and is the same like in Opera and Firefox. I'd like to mark this bug as invalid.

Btw. The example doesn't differ between Safari 5 and WebKit trunk.

[Dirk Schulze]

Can you please upload a new test and add -o-transform and -moz-transform so that we can compare the results with the behavior o other browsers? Maybe it's a bug in -webkit-transform, or the specification of scale is different between CSS and SVG.

Added some CSS transform experts to the bug. Maybe they can look at the example as well.

[Alan Tam]

Created attachment 91428 [details]
updated test case with mozilla and opera support

[Alan Tam]

Created attachment 91429 [details]
test results on Snow Leopard

[Alan Tam]

Hi Dirk,

Please refer to the attached screenshot of my test results for the discussion below.

It is not a kerning issue, but whether to align every glyph of the font onto the pixel grid. Note from the test results (test case 3) that all 4 browsers except Firefox does attempt to align every glyph to the pixel grid. Hence, every "i" is rendered in the same color (colored due to subpixel-antialiasing). Personally I don't care which way the browsers renders.

For HTML with scaling (test case 2), I expect browsers, even if they align to pixel grid, aligns to the grid that is 100x larger (i.e. when the font is 1100px large). Hence, every "i" is rendered in different color. All browsers seem to agree with this.

Test results (test case 1) with all browsers except WebKit trunk are same as what I expected, which is the same as rendering HTML unscaled.

I don't care whether to revert to Safari 5's behavior or follow Firefox 4's, but I believe the current one in WebKit trunk is a bug. In fact no browser agree with current WebKit trunk's behavior.

[Dean Jackson]

Alan, to clarify you're asking that the rendering revert to the previous behaviour, which is that the "i"s are different colours? And that would then match the HTML rendering (which has not changed)?

I don't think this has much to do with CSS transforms.

[Alan Tam]

(In reply to comment #6)
> Alan, to clarify you're asking that the rendering revert to the previous behaviour, which is that the "i"s are different colours? And that would then match the HTML rendering (which has not changed)?

Yes, except "match the HTML rendering" should mean "match the HTML rendering of Firefox". Somehow Safari chooses to render all HTML text by aligning all glyphs to pixel grid (3rd row of 1st and 2nd columns in the screenshot). I don't know the reason (faster rendering?) but I believe it is irreverent to this discussion.


> I don't think this has much to do with CSS transforms.

Right, except for the caveat above. "Safari's HTML rendering" cannot be used to demonstrate expected behavior since it simply the unexpected behavior that I am complaining about. "Safari's HTML rendering with CSS transform" is what I want, so I simply used it to demonstrated what I expected to happen. You can safely ignore it given now we have the screenshot.

[Simon Fraser (smfr)]

<rdar://problem/9357575>

[Nikolas Zimmermann]

Alan, I'm not 100% sure what you're actually asking for, can you re-explain?
I've compared WebKit trunk with Opera, and we render it exactly identical.