313505 - svg text is misplaced, text-anchor="middle" does not work

Status: RESOLVED DUPLICATE of bug 293852

(Core :: SVG, defect)

Description

[Richard Harris]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051023 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051023 Firefox/1.5

text-anchor="middle" seems to cause the text to stray well away from where it is supposed to be, often by mysterious amounts.

In addition to the problem example in the URL, see
http://rhel.cnchost.com/rh/madweave/test-buttons.svg

Reproducible: Always

Steps to Reproduce:
1. start a recent build
2. go to the one of the urls above
Actual Results:  
text is away from where it supposed to be.

Expected Results:  
in my examples, each letter is supposed to be in the center of the boxes.  

These eamples work correctly in IE, with Adobe's svg plugin.

Comment 1

[Magnus Holmgren]

While the example could have used wholer numbers, it suffices to demonstrate the bug. I see it too, in Deer Park (rc1), on Debian Linux. Apparently the string display width isn't calculated correctly and so the text is misaligned.

Comment 2

[Richard Harris]

The offset that is given to the text because of text-anchor="middle" is computed by layout\svg\base\src\nsSVGTextFrame.cpp, in UpdateGlyphPositioning.  It is computed from the x_advance in the metrics from a nsSVGGlyphFrame (pre-computed by a previous call to nsSVGGlyphFrame::NotifyMetricsUnsuspended, which called mMetrics->Update).  When UpdateGlyphPositioning calls SetGlyphPosition, however, it uses the glyphframe's geometry object.

The basic problem seems to be that the metrics object and the geometry object use different scaling, and UpdateGlyphPositioning is written assuming they use the same scaling.  The geometry object uses in its methods the scaling passed in by the constructor, as expected.  On the other hand, if you look at the constructor for the metrics object and at  and other methods such as GetSubBoundingBox, it does not appear to use the constructor's argument nsISVGGlyphMetricsSource *src, and it uses instead the variable mCT, from a call to cairo_create(gSVGCairoDummySurface).  

Comment 3

[Robert Longson [:longsonr]]

Looks to me like GetGlobalTransform needs to be moved from nsSVGCairoGlyphGeometry to nsSVGCairoGlyphMetrics and used in the metrics code too. nsSVGCairoGlyphMetrics ::mExtents would go and be replaced by a calculation done each call. I.e. the code would be moved from nsSVGCairoGlyphMetrics::Update. 

Most nsSVGCairoGlyphMetrics functions would then call cairo_create, GetGlobalTransform and finally cairo_destroy, just as the nsSVGCairoGlyphGeometry do now.

Comment 4

[Robert Longson [:longsonr]]

Hmm, that fixes your example but breaks
http://www.w3.org/Graphics/SVG/Test/20030813/htmlframe/full-text-align-01-b.html

Comment 5

[Robert Longson [:longsonr]]

I don't think this has anything to do with metrics object vs geometry object scaling.

From my investigation, it looks like this is an issue with using small fonts i.e. with a size less than 0.5 within cairo/win32. For instance if you change the font-size in your example to 1 it works (albeit with a big 2).

cairo-win32-font.c has a function _compute_transform which is used to calculate the logical_size of a font. This rounds up to the nearest whole number as it has to be passed to _win32_scaled_font_get_scaled_hfont which puts it into a LOGFONT structure that needs an integer value.

If I multiply all coordinates by 10 in your example it works. 

Comment 6

[Robert Longson [:longsonr]]

Attachment: example with everything x 10

Comment 7

[Robert Longson [:longsonr]]

Looks like this is the same as bug 293852 which also uses really small font-size attributes. Marking this as a duplicate since the other one was raised first.

*** This bug has been marked as a duplicate of 293852 ***