Re: ftview segfault on ArefRuqaaInk-Regular.ttf (one of google web fonts)

[Hin-Tak Leung]

I haven't found the actual librsvg commit which gives the current crash, but I downloaded some old librsvg binaries from fedora's build farm and just LD_LIBRARY_PATH the older versions. So ftview did not die of memory exhaustion against the much older 2.52.7, but start to do so with 2.53.2 onwards, and definitely with 2.56.0 now. The breakage is with 2.53+, I guess. Werner is lucky to have the older two-year-old librsvg 2.52.x .

I'll propose polishing up the diff below.


It looks like this is a frequently debated/change-around issue on librsvg, about getting a "natural size" for svg where none is declared - there are some current issues but also a big rewrite just before 2.52 e.g.

https://gitlab.gnome.org/GNOME/librsvg/-/issues/641
https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/417
with a big "THIS IS A BEHAVIOR CHANGE"


Oh, found the definitive answer - in my /usr/include/librsvg-2.0/librsvg/rsvg.h , it says so:

* Before librsvg 2.54.0, the `out_has_width` and `out_has_height` arguments would be set to true or false
* depending on whether the SVG document actually had `width` and `height` attributes, respectively.
*
* However, since librsvg 2.54.0, `width` and `height` are now [geometry
* properties](https://www.w3.org/TR/SVG2/geometry.html) per the SVG2 specification; they
* are not plain attributes. SVG2 made it so that the initial value of those properties
* is `auto`, which is equivalent to specifing a value of `100%`. In this sense, even SVG
* documents which lack `width` or `height` attributes semantically have to make them
* default to `100%`. This is why since librsvg 2.54.0, `out_has_width` and
* `out_has_heigth` are always returned as `TRUE`, since with SVG2 all documents *have* a
* default width and height of `100%`.
*

On Thursday, 25 May 2023, 00:28:31 BST, Hin-Tak Leung <hintak_leung@yahoo.co.uk> wrote:

I think I have gotten to the bottom of the segfault problem. Pretty sure it is the librsvg people being clever/helpful somewhere between Werner's version and current.

rsvg_handle_get_intrinsic_dimensions() for this header (literal from a a previous message in this thread):

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1">...
</svg>

is supposed to fail to return any width and height, which is probably what Werner's older librsvg does. And the ft demo code would set the svg dimension to units_per_EM when it fails.

dimension_svg.width = units_per_EM;
dimension_svg.height = units_per_EM;

but in my newer/current librsvg it returns with a success of 1x1 (I think that's just a "convenient assumption" to go for unit square for intended size when there is no info ), so it is out by a factor of 1000x1000 .

I'll see if I can find the actual change, but I believe the below is the correct fix:

===
@@ -243,6 +243,10 @@
{
dimension_svg.width = (int)out_width.length; /* XXX rounding? */
dimension_svg.height = (int)out_height.length;
+ if (((int)out_width.length == 1) && ((int)out_height.length == 1)) {
+ dimension_svg.width = units_per_EM;
+ dimension_svg.height = units_per_EM;
+ }
}
else

{
===