Page MenuHomePhabricator

SVG font scaling bug ("%" and "em" misconverted to "px")
Closed, ResolvedPublic

Description

Author: FT2.wiki

Description:
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>

</text>

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>

</text>

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.)


Version: unspecified
Severity: normal

Details

Reference
bz13494

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:03 PM
bzimport set Reference to bz13494.
bzimport added a subscriber: Unknown Object (MLST).

FT2.wiki wrote:

(Initial report and examples: bug 13486 )

FT2.wiki wrote:

Work-around - state font sizes as "px" rather than "%" or "em" for now.

az6024283313 wrote:

What are you people talking about? I am not technical enough to understand that.

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).

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.

giving SVG bugs back to the pool.

Fix committed upstream on 2010-05-02

It seems the dy offset is fixed, but the font size still seems present in our live deploy ?

This issue still is present with our librsvg version it seems.

This issue is now fixed. This is visible in revision 20:06, 23 March 2008 of file http://en.wikipedia.org/wiki/Image:BLP_flowchart_2.svg

which now renders correctly.