bug#36315: 27.0.50; SVG transparency handling is inaccurate

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

On Mon, 01 Jul 2019 23:11:31 +0900,
Eli Zaretskii wrote:
> 
> > Date: Mon, 01 Jul 2019 12:46:55 +0900
> > From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> > Cc: pipcet@gmail.com,
> > 	36315@debbugs.gnu.org
> > 
> > > 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.
> 
> Not sure what this alludes to.

The correspondence is:

  libcairo - Emacs core functionality
  librsvg  - Major/minor mode (e.g., Org mode)

Major/minor modes are not designed to be used in their own right, but
with (the direct use of) Emacs core functionality.  Would Org mode
users complain that it looks like they are using Emacs and not Org
mode?

Even the current SVG support code does something like this:

  /* Create a new RsvgHandle object.  */
  rsvg_handle = rsvg_handle_new ();

  /* Do some tasks with rsvg_handle.  */

  /* Free the RsvgHandle object.  */
  g_object_unref (rsvg_handle);

Do you reject this code because it looks like we are using gobject and
not librsvg?

> One thing that bothers me with using sub-libraries is that we now need
> another entry in dynamic-library-alist, which means complications if
> Cairo ever changes its ABI and we will need to use libcairo-N.dll
> where N > 2.

The patch also removes the entry for gdk-pixbuf, so the situation is
not getting worse.

FWIW, if we want to fix bug#35548 (use of rsvg_handle_write and
rsvg_handle_close that are being deprecated), then we will need to add
an entry for gio.

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