674603 - Text scaled, rotated 90 degrees and with text-anchor="middle" does not render correctly

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Trevor]

Attachment: Example svg showing issue

With the attached example the baseline of the first text element "steps" halfway along the text.

I am using Ubuntu 11.04, I get the same results on Firefox versions 5-8 and SeaMonkey versions 2.1-2.5

Comment 1

[Trevor]

Attachment: The example in Firefox

Comment 2

[(mostly gone) XtC4UaLL [:xtc4uall]]

WFM against Mozilla/5.0 (Windows NT 5.1; rv:8.0a1) Gecko/20110727 Firefox/8.0a1 ID:20110727031559 => no Windows Issue at least.

Comment 3

[Brian Birtles (:birtles)]

Yeah, seems to be ok on Mac too when I checked. Seems to be Linux-specific. Trevor, I wonder if you could paste the "Graphics" section from about:support?

Comment 4

[Trevor]

Graphics
Adapter Description: NVIDIA Corporation -- GeForce FX Go5200/AGP/SSE2
Driver Version: 2.1.2 NVIDIA 173.14.30
WebGL Renderer: Blocked for your graphics driver version. Try updating your graphics driver to version NVIDIA 257.21 or newer.
GPU Accelerated Windows: 0/1. Blocked for your graphics driver version. Try updating your graphics driver to version NVIDIA 257.21 or newer.

Comment 5

[Robert Longson [:longsonr]]

Trevor,

Can you try updating your graphics driver as suggested in comment 4?

Comment 6

[Trevor]

(In reply to comment #5)
> Trevor,
> 
> Can you try updating your graphics driver as suggested in comment 4?

The one I have installed is apparently the only one that will work with my hardware.

Comment 7

[Daniel Holbert [:dholbert]]

My rendering (nightly build, Ubuntu 11.04) matches Trevor's, FWIW.

Comment 8

[Daniel Holbert [:dholbert]]

(I have a much newer graphics driver than he does, though -- "3.0 NVIDIA 270.41.06")

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (simplified)

Here's a reduced testcase, using 4 dash characters (rotated 90 degrees so they're vertical).  It looks basically like this on my system:
  |
  |
 |
 |

The values in the example are very precisely balanced to trigger the bug, too -- in particular, in this chunk of this testcase...
>  <text transform="scale(0.9) translate(15,20) rotate(-90)"
... the "0.9" and the "15" there are both very special.

The bug goes away if I use a scale of 0.89 or 0.91 instead of 0.9, and it also goes away if I use an x-translation of 14.9 or 15.1 instead of 15.

(Those alternate values all shift one of the misaligned chunks to line up with the other one.)

Comment 10

[Daniel Holbert [:dholbert]]

I was hoping a frame tree might help here, but I don't think it does -- we apparently just have a single SVGGlyph frame for all of the text. It looks like this (using testcase 2):
>        SVGText(text)(1)@0x7f7c8ab5eb18 {0,0,0,0} [state=0000000000200000] [content=0x7f7c8cd7b7b0] [sc=0x7f7c8ab5ea30]<
>          SVGGlyph(0)@0x7f7c8ab5ec68 {-60,480,1140,1200} [content=0x7f7c896b7080] [sc=0x7f7c8ab5ebc8]
>        >

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to comment #9)
> [the bug] goes away if I use an x-translation of 14.9 or 15.1 instead of 15.

In fact, here's some probably unnecessary detail:
 x-translation 14.99999952 --> aligned correctly
 x-translation 14.99999953 --> buggy
 [... buggy range continues ...]
 x-translation 15.00000047 --> buggy
 x-translation 15.00000048 --> aligned correctly

Comment 12

[Trevor]

The original situation I have is embedded in an xul popup menu. I cannot reproduce that particular result in any situation other than the one that I am using, it works fine in other xul elements, as a svg file, or embedded in a html page. The font size and rotate are the same as the testcase, but the scale is 0.4. It also does the "step" in the middle of a tspan, which I have been unable to reproduce in other situations at all.

Comment 13

[Trevor]

I just had a friend reproduce this on Fedora 15 with Gnome 3. So it is not Ubuntu specific.

Comment 14

[Daniel Holbert [:dholbert]]

So I can "fix" this with a manual bit of tweaking when I hit this chunk of code, called indirectly by nsSVGGlyphFrame::PaintSVG:

1644 PRBool
1645 CharacterIterator::SetupForDirectTextRun(gfxContext *aContext, float aScale)
1646 {
1647   if (!mPositions.IsEmpty() || mInError)
1648     return PR_FALSE;
1649   aContext->SetMatrix(mInitialMatrix);
1650   aContext->Translate(mSource->mPosition);
1651   aContext->Scale(aScale, aScale);
1652   return PR_TRUE;
1653 }
http://mxr.mozilla.org/mozilla-central/source/layout/svg/base/src/nsSVGGlyphFrame.cpp

Specifically, the "Translate" line there messes us up.

In my attached testcase #2, we have at that point:
mInitialMatrix = {
  xx = 4.0406931273162527e-11, 
  yx = -0.89999997615814209, 
  xy = 0.89999997615814209, 
  yy = 4.0406931273162527e-11, 
  x0 = 13.5, 
  y0 = 9
}

but at line 1650, we do a "Translate()" by mSource->mPosition == (-11.11,0) and we end up with aContext->CurrentMatrix() as:
{
  xx = 4.0406931273162527e-11, 
  yx = -0.89999997615814209, 
  xy = 0.89999997615814209, 
  yy = 4.0406931273162527e-11, 
  x0 = 13.499999999551035, 
  y0 = 19.000000211927613
}

Note in particular the change in "x0".  That's a change of 4e-10. If I manually tweak mInitialMatrix.x0 to be slightly larger so this stays at or above 13.5, then we render correctly.  Changing the matrix's other values, though, doesn't seem to have any effect on the bug.  (I was tweaking them to match values in a matrix encountered at this point in the code for a non-buggy testcase-variant generated per comment 11)

Not sure that helps much, but that's what I've gotten so far.

Comment 15

[Robert Longson [:longsonr]]

(In reply to comment #14)

I wonder if the patches in bug 602759 fix this then.

Comment 16

[Daniel Holbert [:dholbert]]

Good suggestion -- they do, in fact! I applied the rollup patch to today's mozilla-central (w/ fuzz, for one minor change in contextual code), and it fixes both attached testcases.

Adding dependency.

Comment 17

[Daniel Holbert [:dholbert]]

(that roll-up being attachment 544729 [details] [diff] [review] )

Comment 18

[Robert Longson [:longsonr]]

Fixed by bug 602759