383408 - Character position in scaled SVG <foreignObject> text broken

Status: RESOLVED WONTFIX

(Core Graveyard :: GFX, defect)

Description

[Matthew Middleton (:zzxc)]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070531 Minefield/3.0a5pre

Bug 377201 fixed the (win32 only) problem of incorrect scaling of fonts when the containing object is scaled via an SVG foreignObject.  However, the positioning of characters is still broken in Windows, as is seen in the screenshots of that bug and verified with current trunk builds.  (The spacing between characters is not uniform)

Additionally, when the position of the containing block is changed, the character spacing is also changed.  This is seen in a simple button testcase - the character spacing changes when the button is depressed.  The testcase from Bug 377201 demonstrates this; I will upload it to this bug as well.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Matthew Middleton (:zzxc)]

Attachment: Simple button testcase

Comment 2

[Matthew Middleton (:zzxc)]

Attachment: Demonstration of testcase (screenshot)

Comment 3

[Matthew Middleton (:zzxc)]

This bug still occurs in the latest trunk builds, in both Windows and Linux.  (I just checked with the 20070806 build)

Comment 4

[Eli Friedman]

I think the issue here is essentially that we don't account for scaling when doing hinting.  Not sure what we want to do here...

Comment 5

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

We don't want gross layout to change due to a change in transform, so we can't make hinting depend on transform.

We *could* implement text-rendering:geometricPrecision to disable hinting, then authors could use it to fix situations like this. That's doable but not a 1.9 priority. Maybe we should morph this bug to be about that.

Comment 6

[Matthew Middleton (:zzxc)]

Would hinting explain the different character positioning based on screen position?  When the button is depressed, the "A" in "An" and the "b" in "button" is positioned further from the subsequent letter.  (Depressing the button simply changes the padding values for the button, changing the text's position within the scaled object)

Comment 7

[Eli Friedman]

Actually, I'm not so sure this is being caused by hinting exactly; it's quite possible the issue is that the Windows APIs don't support subpixel glyph placement/rendering.

Comment 8

[Matthew Middleton (:zzxc)]

This same bug also occurs with Linux, so it can't be Windows specific.  It does not occur with Mac builds.  (A screenshot of this testcase working with a Mac build is here:  https://bugzilla.mozilla.org/attachment.cgi?id=261421)

  

Comment 9

[Eli Friedman]

The fact that it doesn't occur on Mac basically confirms my suspicion; IIRC only the Mac APIs support subpixel glyph positioning.

Comment 10

[Robert Longson [:longsonr]]

The testcase still changes on Windows when the button is clicked but that may be due to it not having text-rendering:geometricPrecision in which case this bug is likely invalid.

Comment 11

[Gordon P. Hemsley [:GPHemsley]]

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]