bug#36315: 27.0.50; SVG transparency handling is inaccurate

[YAMAMOTO Mitsuharu]

On Sun, 30 Jun 2019 23:26:51 +0900,
Eli Zaretskii wrote:
> 
> > Date: Sun, 30 Jun 2019 15:12:18 +0900
> > From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> > Cc: pipcet@gmail.com,
> >     36315@debbugs.gnu.org
> > 
> > > > > > What kind of operations do you think librsvg should provide us with,
> > > > > > instead of letting us use cairo?
> > > > > 
> > > > > Those for which you called the Cairo functions directly.
> > > > 
> > > > Which one, concretely?  Or you mean something in other parts?
> > > 
> > > All of the Cairo functions you called:
> > > 
> > >    cairo_create
> > >    cairo_destroy
> > >    cairo_image_surface_create
> > >    cairo_image_surface_get_data
> > >    cairo_image_surface_get_stride
> > >    cairo_paint
> > >    cairo_set_source_rgb
> > >    cairo_surface_destroy
> > >    cairo_surface_flush
> > >    cairo_surface_status
> > 
> > Why do you think so?  Librsvg does not provide us with any further
> > abstractions over the cairo data structures.
> 
> It just looks like we are using libcairo and not librsvg.
>
> Again, it isn't something entirely rational, it just sounds weird to
> me.  Imagine that users libxml2 would need to call libiconv to decode
> UTF-8 encoded text in an XML file, for example.  Doesn't look right.

The situation for libcairo and librsvg should be familiar to us: we
are directly using Emacs core functionality even when working with
several major or minor modes.

Anyway, this is the librsvg design we cannot change here.  The
situation for another SVG rendering library resvg
(https://github.com/RazrFalcon/resvg), which supports multiple
backends, looks similar in the above respect at first glance.

                                     YAMAMOTO Mitsuharu
                                mituharu@math.s.chiba-u.ac.jp