GNU bug report logs - #36315
27.0.50; SVG transparency handling is inaccurate

Previous Next

Full log

Message #32 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36315 <at> debbugs.gnu.org, pipcet <at> gmail.com,
 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Tue, 25 Jun 2019 19:44:28 +0100

On Tue, Jun 25, 2019 at 07:54:52PM +0300, Eli Zaretskii wrote:
> > 3. Image transformations can be applied when rendering to the cairo
> >    surface, not after generating bitmaps.  So we can take advantage of
> >    outline format and get better results of scaling.  This is not in
> >    the patch.  Probably it should be done by a separate commit after
> >    general image transformation code has been stabilized.
> 
> Maybe it's just me, but I'm uneasy to bypass librsvg and call Cairo
> directly for manipulating SVG images.  Why doesn't librsvg provide a
> way to do this via its own APIs?
> 
> Does anyone else think it's unusual to make such direct calls to what
> is essentially a lower-level library?

Librsvg doesn’t provide any way to modify the images. It loads them
into either ‘GIO’ format (whatever that is), Cairo, or a pixel buffer.
There are functions for use with a GDKPixBuf that allow scaling, but
they’re now deprecated in favour of using Cairo.
-- 
Alan Third

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.