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

Previous Next

Full log

View this message in rfc822 format

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36315 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Wed, 26 Jun 2019 08:48:25 +0900

On Wed, 26 Jun 2019 01:54:52 +0900,
Eli Zaretskii wrote:
> 
> > Date: Tue, 25 Jun 2019 08:06:23 +0900
> > From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> > Cc: pipcet <at> gmail.com,
> > 	36315 <at> debbugs.gnu.org
> > 
> > > The patch looks quite large.  Do we gain anything significant, apart
> > > of the appraisal of librsvg developers?
> > 
> > 1. The current librsvg generates gdk-pixbuf via cairo image surface.
> >    So we can avoid unnecessarily intermediate data structure and
> >    roundtrip of alpha-component processing using cairo directly.
> > 2. If configured --with-cairo, we can do further shortcut.  This is
> >    included in the patch attached to this mail.  Pip's patch is also
> >    reflected.
> > 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?

What kind of operations do you think librsvg should provide us with,
instead of letting us use cairo?

BTW, GTK 4 is deemphasizing GdkPixbuf:

  https://developer.gnome.org/gtk4/stable/ch29s02.html#id-1.6.4.4.33

I don't think GdkPixbuf is dropped from GTK/GDK soon, but we don't
have any particular reasons to stick to it for rendering SVG images.

> > > I've built the patch on Windows (you forgot cairo_surface_destroy, so
> > > I needed to add it), but the result is strange, or maybe I don't
> > > understand what is expected.  I don't see any rectangle of color
> > > #f00000, I see the entire frame with black background, and a few
> > > characters in other colors.
> > 
> > When I tested Pip's test case, I started with emacs -Q -rv to avoid
> > text becomes invisible.  I could see a red rectangle on X11.  Do you
> > see such a rectangle without my patch?
> 
> Yes, I see an orange rectangle (a square, actually, I think).

If the square is not displayed with my patch, then there is a bug in
it.  I've sent 3 versions and the first one was wrong.  Please try
again with the latest one in my previous mail:

  https://debbugs.gnu.org/cgi/bugreport.cgi?att=1;msg=26;bug=36315;filename=svg-cairo.diff

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Previous Next

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