If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED DUPLICATE of bug 293852

Status

()

Core
SVG
RESOLVED DUPLICATE of bug 293852
12 years ago
12 years ago

People

(Reporter: Richard Harris, Unassigned)

Tracking

1.8 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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.
(Reporter)

Updated

12 years ago
Version: Trunk → 1.8 Branch

Comment 1

12 years ago
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.
(Reporter)

Comment 2

12 years ago
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

12 years ago
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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Updated

12 years ago
Assignee: general → longsonr
Status: ASSIGNED → NEW

Comment 4

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

Comment 5

12 years ago
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

12 years ago
Created attachment 211740 [details]
example with everything x 10

Updated

12 years ago
Attachment #211740 - Attachment description: as previous attachment with everything x 10 → example with everything x 10

Updated

12 years ago
Assignee: longsonr → general

Comment 7

12 years ago
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 ***
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.