bug#36315: 27.0.50; SVG transparency handling is inaccurate

[Eli Zaretskii]

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

> > This works, but I don't think I see any difference in the color of the
> > rectangle wrt what I see in Emacs 26, i.e. without the patch.
> 
> Usually the sense of sight by human cannot see the difference between
> the colors #ef0000 and #f00000.  You would need some color picker to
> tell the difference.

OK, then please ignore that remark.