bug#36315: 27.0.50; SVG transparency handling is inaccurate

[Eli Zaretskii]

> Date: Tue, 25 Jun 2019 08:06:23 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: pipcet@gmail.com,
>       36315@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?

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