373896 - SVG Text Does Not Scale Correctly

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[Duncan Loveday]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2

When an SVG document is scaled (e.g. using SVGRoot.currentScale*=2) the text within the document is also scaled but not by the correct proportion.

The attached test case initially renders a document with a line of text and a rectangle, one above the other and having the same width. When the document is scaled the rectangle and text scale by different amounts. The rectangle is scaled correctly as proved by the presence of another adjoining rectangle, but the text is incorrect.

Reproducible: Always

Steps to Reproduce:
1. Put the attached test.svg and test.html in a directory
2. Open test.html in Firefox.
3. Observe that the text and black rectangle both adjoin the red rectangle.
4. Use the "zoom out" and "zoom in" buttons to scale the image.
5. Observer that the black rectangle scales correctly but that the text does not.
Actual Results:  
Depending on the level of zoom, the text is either too large or too small and by different amounts - I have not been able to discern an obvious pattern.

Expected Results:  
The text and black rectangle should scale together and both should adjoin the red rectange at all times.

This test case works correctly in IE6 with the Adobe viewer version 3.

I've tried using a zoom event handler to re-evaluate "getComputedTextLength()" and re-size the black rectangle but "getComputedTextLength()" returns the same result regardless of scale (which I think is correct behaviour). It is just that the text is rendered at the wrong size.

Comment 1

[Duncan Loveday]

Attachment: SVG test source

Comment 2

[Duncan Loveday]

Attachment: test HTML source

Comment 3

[Robert Longson [:longsonr]]

I think cairo creates fonts with integer font sizes (as that's what the windows LOGFONTW structure allows) which would mean that font sizes would get rounded to the nearest integer. Perhaps cairo may do something more sophisticated in the future.

Comment 4

[Robert Longson [:longsonr]]

Also FWIW your testcase assumes a relationship between the order of onload in the html body and onload in the embedded svg which is likely not to hold going forward. setTimeout can be used to alleviate this.

Comment 5

[Duncan Loveday]

Re integer font sizes that sounds like a plausible enough reason for the behaviour but the bug still stands. If Cairo can't scale fonts accurately then a way around that limitation has to be found in a correct implementation of a scalable graphics library that includes text.

This is playing havoc with my SVG layouts where I have text in boxes that are sized to fit.

Re onload SVG vs onload HTML I've only made use of the HTML onload event to work around bug 373252 where getComputedTextLength() doesn't work from the SVG onload handler. If that gets fixed in the future then I'll revert to what I had before, doing it all from the SVG onload handler, but as of today I know of no other reliable workaround than to assume the load order.

Comment 6

[Eli Friedman]

See also Bug 372838?

Comment 7

[Duncan Loveday]

Have had a look at bug 327838 - I'm not instantly sure the two are related since that bug is a recent regression whereas the behaviour I'm seeing is the same in both FF 2 and 3.

On reflection I have decreased the severity of this since it is largely liveable with. I can easily implement a partial workaround by adding 5% or so to the result of getComputedTextLength() which at least prevents the text overflowing its prescribed area unless the image is displayed at a very small scale.

I do think this ought to be addressed at some point though. When progressively zooming out, a point is reached after which the text never gets any smaller (perhaps because it has reached a 1px size) but the rest of the image does and there is no simple workaround for that.

Text ought to be linearly scaled and if only integer font sizes are available this can't be correctly accomplished by substituting font sizes.

Comment 8

[Robert Longson [:longsonr]]

Do try it now with a current trunk build. I think thebes conversion has improved things.

Comment 9

[Duncan Loveday]

Attachment: test HTML source

Version that works live in the bug

Comment 10

[Duncan Loveday]

Attachment: test HTML source

Attaching a version that does not rely on load ordering of SVG happening before HTML, since this appears to have changed since the version against which the bug was raised.

Comment 11

[Duncan Loveday]

Attachment: test HTML source

Fixing a bug introduced in the last version, will get there in the end...

Comment 12

[Duncan Loveday]

Looking good in version

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070422 Minefield/3.0a4pre

Comment 13

[Robert Longson [:longsonr]]

Closing as WFM in light of the raising of bug 378404.

Comment 14

[Duncan Loveday]

Robert, I'm not sure of the difference between "Works for me" and "Fixed" but the issue I originally raised in this bug is definitely fixed. Give yourselves credit where it's due !

I'm quite delighted, BTW, it sounded from the initial responses as if this wasn't going to be a trivial change.

Comment 15

[Robert Longson [:longsonr]]

(In reply to comment #14)
> Robert, I'm not sure of the difference between "Works for me" and "Fixed" but
> the issue I originally raised in this bug is definitely fixed. Give yourselves
> credit where it's due !
> 

I suspect thebes conversion fixed it but it could be a cairo update and I can't be bothered to check :-). If I knew for sure I would make it a duplicate.

www.mozilla.org/quality/help/bugzilla-privilege-guide.html

Comment 16

[Duncan Loveday]

This seems to be broken again since bug 392233 landed.

Comment 17

[Robert Longson [:longsonr]]

This is invalid. You need to recalculate getComputedTextLength if you zoom.

Glyph metrics do not necessarily scale uniformly with change in scale. The effects of kerning, hinting etc vary with scale.

Comment 18

[Duncan Loveday]

Bummer. I'd have thought the whole thing should just get bigger and smaller (as in ASV). Still, if that's what the SVG spec says, fair enough.

I'll either have to re-layout and re-draw the whole SVG image from the zoom event or else allowing spare room wherever I have text inside boxes that are sized to fit. Not at all convenient but there it is.

Comment 19

[Robert Longson [:longsonr]]

It's a choice that was made for Gecko. The explanation is here http://weblogs.mozillazine.org/roc/archives/2007/10/a_tale_of_two_z.html

Comment 20

[Duncan Loveday]

Robert, thanks.

Comment 21

[Duncan Loveday]

Robert, are you sure you're not in violation of the SVG spec with this approach ? The information at http://www.w3.org/TR/SVG/coords.html#ScalingDefined seems to imply a simple linear scaling is a requirement.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That doesn't say text metrics have to scale linearly with the CTM. You actually can't do that and simultaneously have text that looks good at different scales.

However, if you apply text-rendering:geometricPrecision, you will get metrics that scale linearly with the CTM, at the expense of the text not looking as good.

Comment 23

[Duncan Loveday]

Attachment: SVG test source with and without text-rendering:geometricPrecision

ROC, cheers for that and the text-rendering attribute works nicely. Attaching an example in case other bugs are duped against this on, people will be able to see the solution.