bug#44206: 28.0.50; SVG image fail to show

[Alan Third]

On Sun, Oct 25, 2020 at 12:17:16PM -0500, Sheng Yang wrote:
> Thanks for your effort! Patch works for me, librsvg 2.50 on Archlinux. 
> 
> On Sun, Oct 25, 2020, at 11:01, Alan Third wrote:
> > Anyway, I've thrown in another attempt at calculating the image size,
> > and it works for this and also for the previous images. This one is
> > more complex because it's trying to convert CSS sizes to pixel sizes
> > and I don't think we can be entirely sure of some of them (like ex
> > height? Maybe we can query that, but then we have to know font and
> > font size).
> > 
> > I have no doubt that there are many more SVG files out there that
> > won't display properly even with this patch.
> 
> I checked places where I use SVG files, especially telega,
> everything I checked looks good to me now. Hope there are not too
> many corner cases.

Thanks.

> > librsvg is really not helping here. The documentation makes it pretty
> > clear that they don't want us to be querying the SVG dimensions and
> > would prefer us to just give them the dimensions we want and/or to use
> > Cairo.
> 
> So could the future of SVG in Emacs lie in Cairo? Forgive me if I am
> asking a dumb question.

Not a dumb question. This came up a little while back and I think
there might be potential issues with getting Cairo on Windows, so it's
not necessarily a great solution.

One thing is that, in theory, if we were using SVGs for parts of the
UI, like fringe bitmaps, we wouldn't have to worry too much about
resizing and so on as we control the SVGs and can define them to suit
our uses.

> > > Affected librsvg version: 2:2.50.1-1 in Archlinux, and 2.44.10-2.1 in 
> > > Debian.
> > 
> > I'm concerned that librsvg 2.44 is affected as it should be using the
> > same code path as before the commit in question.
> 
> My fault, librsvg 2.44 on Debian is NOT affect by this. (I guess I
> was having internet issue with my vps running debian. Last time I
> waited for a few seconds and the image was not showing up. I waited
> a bit longer this time.)

Ah, good to know. Thanks!
-- 
Alan Third