Last modified: 2012-10-26 09:03:17 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T15494, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 13494 - SVG font scaling bug ("%" and "em" misconverted to "px")
SVG font scaling bug ("%" and "em" misconverted to "px")
Product: Wikimedia
Classification: Unclassified
SVG rendering (Other open bugs)
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: svg
  Show dependency treegraph
Reported: 2008-03-24 20:55 UTC by FT2
Modified: 2012-10-26 09:03 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description FT2 2008-03-24 20:55:52 UTC
SVG images containing text elements whose sizes are given in "%" or "em" (and possibly other non-px units?), do not correctly convert sizes such as "120%" or "2em" to their px equivalents, causing serious rendering errors.

Example #1:

<text style="font-size:14px;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Arial">
   <tspan x="13" y="25" font-weight = "bold" font-size = "120%">HEADER</tspan>

fails, and renders the font as 120px (!).  If the "120%" is replaced by its exact px equivalent "16.8px" (=14px x 120%) it succeeds. The effect of this bug is the font renders at a huge size, causing large (often black) rectangles and "letterboxes" to hide part or all of the image, or indeed not being visible at all.

Example #2:

<text style="font-size:14px;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Arial">
   <tspan x="13" y="25">HEADER</tspan>
   <tspan x="13" dy="2em">My paragraph text</tspan>

fails (puts 2nd line on same y-co-ordinate as first line rather than 2 lines below it).  If the "2em" is replaced by its exact px equivalent "28px" (=14px x 2) it succeeds.

(May also affect rendering of other elements that can have sizes given in "%" or "em" terms too.)
Comment 1 FT2 2008-03-25 04:02:26 UTC
(Initial report and examples:  bug 13486 )
Comment 2 Nobody 2008-03-26 04:01:23 UTC
librsvg bug,
Comment 3 FT2 2008-03-26 04:09:16 UTC
Work-around - state font sizes as "px" rather than "%" or "em" for now.
Comment 4 Chris 2008-05-24 22:03:19 UTC
What are you people talking about? I am not technical enough to understand that.
Comment 5 Brion Vibber 2008-05-27 20:06:02 UTC
Translation: there's a bug in the library we use to render SVG images. It's possible to work around it by making your SVG files in a slightly different way (specify font sizes in pixel units instead of percentage or "em" height).
Comment 6 Brion Vibber 2009-08-03 16:53:51 UTC
Assigning SVG bugs to Ariel -- need a cleanup pass to see what's fixed up by a librsvg upgrade, what can be resolved with fixes to our font configuration, what can be fixed on our end, and what still needs to be pushed upstream.
Comment 7 Ariel T. Glenn 2011-09-18 09:14:44 UTC
giving SVG bugs back to the pool.
Comment 8 Derk-Jan Hartman 2011-12-04 13:37:35 UTC
Fix committed upstream on 2010-05-02
Comment 9 Derk-Jan Hartman 2011-12-04 13:44:20 UTC
It seems the dy offset is fixed, but the font size still seems present in our live deploy ?
Comment 10 Derk-Jan Hartman 2012-07-29 23:06:32 UTC
This issue still is present with our librsvg version it seems.
Comment 11 Derk-Jan Hartman 2012-10-26 09:03:17 UTC
This issue is now fixed. This is visible in revision 20:06, 23 March 2008 of file

which now renders correctly.

Note You need to log in before you can comment on or make changes to this bug.