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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36315 in the body.
You can then email your comments to 36315 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; SVG transparency handling is inaccurate
Date: Thu, 20 Jun 2019 20:26:53 +0000

[Message part 1 (text/plain, inline)]

Evaluate the following in emacs -Q:

(require 'svg)

(defun make-image (color)
  (let ((svg (svg-create 100 100)))
    (svg-rectangle svg 0 0 100 100 :fill color)
    (svg-image svg)))

(set-frame-parameter (window-frame) 'background-color "black")

(insert (propertize " " 'display (make-image "#f00000")))

The expected result is a rectangle (on black background) of color
#f00000. The actual result is a rectangle of color #ef0000. For black
backgrounds, white is no longer representable.

This is related to bug #36304, but much easier to fix.

Patch attached.

[0001-SVG-scale-color-values-properly.patch (text/x-patch, attachment)]

Message #8 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: 36315 <at> debbugs.gnu.org
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Thu, 20 Jun 2019 20:46:20 +0000

[Message part 1 (text/plain, inline)]

Oops, typo in the patch. Better patch attached.

Subject: [PATCH] SVG: scale color values properly

* src/image.c (svg_load_image): scale color channel values to proper
range.
---
 src/image.c | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/src/image.c b/src/image.c
index 866323ba6e..8e25f1f590 100644
--- a/src/image.c
+++ b/src/image.c
@@ -9658,17 +9658,20 @@ svg_load_image (struct frame *f, struct image
*img, char *contents,
       {
     for (int x = 0; x < width; ++x)
       {
-        int red     = *pixels++;
-        int green   = *pixels++;
-        int blue    = *pixels++;
-        int opacity = *pixels++;
-
-        red   = ((red * opacity)
-             + (background.red * ((1 << 8) - opacity)));
-        green = ((green * opacity)
-             + (background.green * ((1 << 8) - opacity)));
-        blue  = ((blue * opacity)
-             + (background.blue * ((1 << 8) - opacity)));
+        unsigned int red     = *pixels++;
+        unsigned int green   = *pixels++;
+        unsigned int blue    = *pixels++;
+        unsigned int opacity = *pixels++;
+
+        /* opacity and the color channel values are in the range {0..255},
+         * but expected output values are in the range {0..65535}, so scale
+         * by (256/255)^2. */
+#define MIX(a, b, opacity)                        \
+        (((((a) * opacity) + ((b) * (255 - opacity))) * 65535 + 32512) / 65025)
+        red   = MIX (red, background.red, opacity);
+        green = MIX (green, background.green, opacity);
+        blue  = MIX (blue, background.blue, opacity);
+#undef MIX

         PUT_PIXEL (ximg, x, y, lookup_rgb_color (f, red, green, blue));
       }
-- 
2.20.1


On Thu, Jun 20, 2019 at 8:43 PM Pip Cet <pipcet <at> gmail.com> wrote:
>
> Evaluate the following in emacs -Q:
>
> (require 'svg)
>
> (defun make-image (color)
>   (let ((svg (svg-create 100 100)))
>     (svg-rectangle svg 0 0 100 100 :fill color)
>     (svg-image svg)))
>
> (set-frame-parameter (window-frame) 'background-color "black")
>
> (insert (propertize " " 'display (make-image "#f00000")))
>
> The expected result is a rectangle (on black background) of color
> #f00000. The actual result is a rectangle of color #ef0000. For black
> backgrounds, white is no longer representable.
>
> This is related to bug #36304, but much easier to fix.
>
> Patch attached.

[0001-SVG-scale-color-values-properly.patch (application/x-patch, attachment)]

Message #11 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36315 <at> debbugs.gnu.org
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Sat, 22 Jun 2019 21:56:41 +0100

On Thu, Jun 20, 2019 at 08:46:20PM +0000, Pip Cet wrote:
> Oops, typo in the patch. Better patch attached.

I know nothing about librsvg, but the patch does appear to fix the
described behaviour (although I had to try #FFFFFF because #F00000,
appeared to come out as something else entirely in both cases).
-- 
Alan Third

Message #14 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36315 <at> debbugs.gnu.org
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Mon, 24 Jun 2019 16:56:45 +0900

[Message part 1 (text/plain, inline)]

On Fri, 21 Jun 2019 05:26:53 +0900,
Pip Cet wrote:
> 
> [1  <text/plain; UTF-8 (7bit)>]
> Evaluate the following in emacs -Q:
> 
> (require 'svg)
> 
> (defun make-image (color)
>   (let ((svg (svg-create 100 100)))
>     (svg-rectangle svg 0 0 100 100 :fill color)
>     (svg-image svg)))
> 
> (set-frame-parameter (window-frame) 'background-color "black")
> 
> (insert (propertize " " 'display (make-image "#f00000")))
> 
> The expected result is a rectangle (on black background) of color
> #f00000. The actual result is a rectangle of color #ef0000. For black
> backgrounds, white is no longer representable.
> 
> This is related to bug #36304, but much easier to fix.
> 
> Patch attached.

An alternative way would be to use rsvg_handle_render_cairo, which is
recommended by librsvg, and let it blend with the background color.

Patch attached.  Note that this does not require --with-cairo.
Raising the required version of librsvg to 2.14 is not a problem, as
we are already using rsvg_handle_get_dimensions that requires that
version.  Is Windows librsvg DLL compiled with libcairo?

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

[svg-cairo.diff (application/octet-stream, attachment)]

Message #17 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36315 <at> debbugs.gnu.org
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Mon, 24 Jun 2019 17:17:55 +0900

[Message part 1 (text/plain, inline)]

On Mon, 24 Jun 2019 16:56:45 +0900,
YAMAMOTO Mitsuharu wrote:
> 
> An alternative way would be to use rsvg_handle_render_cairo, which is
> recommended by librsvg, and let it blend with the background color.
> 
> Patch attached.  Note that this does not require --with-cairo.
> Raising the required version of librsvg to 2.14 is not a problem, as
> we are already using rsvg_handle_get_dimensions that requires that
> version.  Is Windows librsvg DLL compiled with libcairo?

Sorry, wrong patch.  Please try this instead.

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

[svg-cairo.diff (application/octet-stream, attachment)]

Message #20 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 36315 <at> debbugs.gnu.org
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Mon, 24 Jun 2019 16:24:17 +0000

[Message part 1 (text/plain, inline)]

On Mon, Jun 24, 2019 at 8:17 AM YAMAMOTO Mitsuharu
<mituharu <at> math.s.chiba-u.ac.jp> wrote:
> On Mon, 24 Jun 2019 16:56:45 +0900,
> YAMAMOTO Mitsuharu wrote:
> >
> > An alternative way would be to use rsvg_handle_render_cairo, which is
> > recommended by librsvg, and let it blend with the background color.
> >
> > Patch attached.  Note that this does not require --with-cairo.
> > Raising the required version of librsvg to 2.14 is not a problem, as
> > we are already using rsvg_handle_get_dimensions that requires that
> > version.  Is Windows librsvg DLL compiled with libcairo?
>
> Sorry, wrong patch.  Please try this instead.

Thank you very much, that fixes the problem. Unfortunately, I do not
know about the situation on Windows.

I'm not sure about the additional changes in the attached relative
patch, so feel free to take or leave them as you see fit. The second
call to cairo_set_source_rgb is currently unnecessary, because rsvg
forces the foreground color to black anyway, but that might change one
day (ideally, we'd use the frame foreground color, or even the current
face's foreground color; I have patches here that do this, though they
don't fix rsvg).

@@ -9619,15 +9619,19 @@ svg_load_image (struct frame *f, struct image
*img, char *contents,

   cairo_surface_t *surface = cairo_image_surface_create (CAIRO_FORMAT_RGB24,
                              width, height);
+  if (cairo_surface_status (surface) != CAIRO_STATUS_SUCCESS)
+    goto rsvg_error;
   cairo_t *cr = cairo_create (surface);
   cairo_set_source_rgb (cr, background.red / 65535.0,
             background.green / 65535.0,
             background.blue / 65535.0);
   cairo_paint (cr);
+  cairo_set_source_rgb (cr, 0.0, 0.0, 0.0);
   rsvg_handle_render_cairo (rsvg_handle, cr);
   cairo_destroy (cr);
   g_object_unref (rsvg_handle);

+  cairo_surface_flush (surface);
   unsigned char *data = cairo_image_surface_get_data (surface);
   int stride = cairo_image_surface_get_stride (surface);
   for (int y = 0; y < height; ++y)
@@ -9636,9 +9640,9 @@ svg_load_image (struct frame *f, struct image
*img, char *contents,
       for (int x = 0; x < width; ++x)
     {
       guint32 rgb = *pixels++;
-      int red   = ((rgb >> 16) & 0xff) << 8;
-      int green = ((rgb >> 8) & 0xff) << 8;
-      int blue  = (rgb & 0xff) << 8;
+      int red   = ((rgb >> 16) & 0xff) * 0x101;
+      int green = ((rgb >> 8) & 0xff) * 0x101;
+      int blue  = (rgb & 0xff) * 0x101;
       PUT_PIXEL (ximg, x, y, lookup_rgb_color (f, red, green, blue));
     }
       data += stride;

[0001-minor-things.patch (text/x-patch, attachment)]

Message #23 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 36315 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Mon, 24 Jun 2019 20:41:03 +0300

> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: 36315 <at> debbugs.gnu.org
> 
> An alternative way would be to use rsvg_handle_render_cairo, which is
> recommended by librsvg, and let it blend with the background color.
> 
> Patch attached.  Note that this does not require --with-cairo.
> Raising the required version of librsvg to 2.14 is not a problem, as
> we are already using rsvg_handle_get_dimensions that requires that
> version.  Is Windows librsvg DLL compiled with libcairo?

librsvg on Windows is indeed build with libcairo, but if we don't get
the --with-cairo option, we don't probe for the necessary functions,
so at least theoretically we could have librsvg without Cairo.

The patch looks quite large.  Do we gain anything significant, apart
of the appraisal of librsvg developers?

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.

Thanks.

Message #26 received at 36315 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Tue, 25 Jun 2019 08:06:23 +0900

[Message part 1 (text/plain, inline)]

On Tue, 25 Jun 2019 02:41:03 +0900,
Eli Zaretskii wrote:
> 
> librsvg on Windows is indeed build with libcairo, but if we don't get
> the --with-cairo option, we don't probe for the necessary functions,
> so at least theoretically we could have librsvg without Cairo.

I found librsvg actually requires libcairo, not optional.  Sorry for
my bogus question and thanks for testing the patch.

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

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

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

[svg-cairo.diff (application/octet-stream, attachment)]

Message #29 received at 36315 <at> debbugs.gnu.org (full text, mbox):

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

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

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

Message #32 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36315 <at> debbugs.gnu.org, pipcet <at> gmail.com,
 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Tue, 25 Jun 2019 19:44:28 +0100

On Tue, Jun 25, 2019 at 07:54:52PM +0300, Eli Zaretskii wrote:
> > 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?

Librsvg doesn’t provide any way to modify the images. It loads them
into either ‘GIO’ format (whatever that is), Cairo, or a pixel buffer.
There are functions for use with a GDKPixBuf that allow scaling, but
they’re now deprecated in favour of using Cairo.
-- 
Alan Third

Message #35 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 36315 <at> debbugs.gnu.org, pipcet <at> gmail.com, mituharu <at> math.s.chiba-u.ac.jp
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Tue, 25 Jun 2019 21:55:42 +0300

> Date: Tue, 25 Jun 2019 19:44:28 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
> 	36315 <at> debbugs.gnu.org, pipcet <at> gmail.com
> 
> > 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?
> 
> Librsvg doesn’t provide any way to modify the images.

Yes, but neither do any of the other image libraries, right?

The issue at hand, I believe, had to do with colors that weren't
right.  Image transformations are a separate issue, and we already
know how to do that for SVG and for other image types.

Message #38 received at 36315 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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

Message #41 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36315 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Wed, 26 Jun 2019 02:12:28 +0200

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

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

I know nothing about cairo, but last time I was playing with font stuff
in SVGs, it seemed like librsvg had very good support for advanced
ligature stuff, while other SVG libraries didn't...  how is cairo on
that front?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #44 received at 36315 <at> debbugs.gnu.org (full text, mbox):

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

> Date: Wed, 26 Jun 2019 08:48:25 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: 	pipcet <at> gmail.com,
> 	36315 <at> debbugs.gnu.org
> 
> > 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?

Those for which you called the Cairo functions directly.

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

I tried with the second patch.  I tried now again with the above one:
still no rectangle.

Thanks.

Message #47 received at 36315 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Thu, 27 Jun 2019 12:33:46 +0900

[Message part 1 (text/plain, inline)]

On Thu, 27 Jun 2019 00:57:48 +0900,
Eli Zaretskii wrote:
> 
> > > 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?
> 
> Those for which you called the Cairo functions directly.

Which one, concretely?  Or you mean something in other parts?

+  cairo_surface_t *surface;
+#ifdef USE_CAIRO
+  surface = cairo_image_surface_create_for_data ((unsigned char *) ximg->data,
+						 CAIRO_FORMAT_RGB24,
+						 width, height,
+						 ximg->bytes_per_line);
+#else
+  surface = cairo_image_surface_create (CAIRO_FORMAT_RGB24, width, height);
+#endif
+  if (cairo_surface_status (surface) != CAIRO_STATUS_SUCCESS)
+    goto rsvg_error;
+  cairo_t *cr = cairo_create (surface);
+  cairo_set_source_rgb (cr, background.red / 65535.0,
+			background.green / 65535.0,
+			background.blue / 65535.0);
+  cairo_paint (cr);
+  cairo_set_source_rgb (cr, 0.0, 0.0, 0.0);
+  rsvg_handle_render_cairo (rsvg_handle, cr);
+  cairo_destroy (cr);
+  g_object_unref (rsvg_handle);

> I tried with the second patch.  I tried now again with the above one:
> still no rectangle.

Seems like a problem in DLL loading.  Please try the attached one.

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

[svg-cairo.diff (application/octet-stream, attachment)]

Message #50 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 36315 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Thu, 27 Jun 2019 17:16:07 +0300

> Date: Thu, 27 Jun 2019 12:33:46 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: pipcet <at> gmail.com,
> 	36315 <at> 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

> > I tried with the second patch.  I tried now again with the above one:
> > still no rectangle.
> 
> Seems like a problem in DLL loading.  Please try the attached one.

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.

Thanks.

Message #53 received at 36315 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Sun, 30 Jun 2019 15:12:18 +0900

On Thu, 27 Jun 2019 23:16:07 +0900,
Eli Zaretskii wrote:
> 
> > Date: Thu, 27 Jun 2019 12:33:46 +0900
> > From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> > Cc: pipcet <at> gmail.com,
> > 	36315 <at> 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.  Also, the first
paragraph of README.md in the source code says:

  This is librsvg - A small library to render Scalable Vector Graphics
  (SVG), associated with the GNOME Project.  It renders SVG files to
  Cairo surfaces.  Cairo is the 2D, antialiased drawing library that
  GNOME uses to draw things to the screen or to generate output for
  printing.

In librsvg, only 2 functions deal with the cairo data structures.
Librsvg is, at least except its very early versions, clearly designed
so it is used together with cairo.

> > > I tried with the second patch.  I tried now again with the above one:
> > > still no rectangle.
> > 
> > Seems like a problem in DLL loading.  Please try the attached one.
> 
> 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.

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

Message #56 received at 36315 <at> debbugs.gnu.org (full text, mbox):

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

> Date: Sun, 30 Jun 2019 15:12:18 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: pipcet <at> gmail.com,
> 	36315 <at> 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.

Message #59 received at 36315 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Mon, 01 Jul 2019 12:46:55 +0900

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 <at> math.s.chiba-u.ac.jp>
> > Cc: pipcet <at> gmail.com,
> > 	36315 <at> 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 <at> math.s.chiba-u.ac.jp

Message #62 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 36315 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Mon, 01 Jul 2019 17:11:31 +0300

> Date: Mon, 01 Jul 2019 12:46:55 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: pipcet <at> gmail.com,
> 	36315 <at> 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.

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.

So on balance, I prefer the original fix, which was much simpler.
Assuming it fixed the problem, of course (I didn't try).

Message #65 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36315 <at> debbugs.gnu.org, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Mon, 1 Jul 2019 16:25:49 +0000

On Mon, Jul 1, 2019 at 2:12 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> So on balance, I prefer the original fix, which was much simpler.
> Assuming it fixed the problem, of course (I didn't try).

I prefer the other fix, for what it's worth, probably for the same
reasons you don't: it makes it easier to add more fancy features
editors don't need, such as true image transparency and SVG
animations. librsvg has painful limitations such as not allowing us to
pass in a foreground color (it simply uses black), but maybe that'll
be better one day, and then this patch would make it easier for us to
use the new features.

The fix looks more complicated than it is because it changes
indentation (for the better) and removes a misleading comment.

Message #68 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36315 <at> debbugs.gnu.org, mituharu <at> math.s.chiba-u.ac.jp
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Tue, 02 Jul 2019 05:32:41 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Mon, 1 Jul 2019 16:25:49 +0000
> Cc: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, 36315 <at> debbugs.gnu.org
> 
> On Mon, Jul 1, 2019 at 2:12 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > So on balance, I prefer the original fix, which was much simpler.
> > Assuming it fixed the problem, of course (I didn't try).
> 
> I prefer the other fix, for what it's worth, probably for the same
> reasons you don't: it makes it easier to add more fancy features
> editors don't need, such as true image transparency and SVG
> animations. librsvg has painful limitations such as not allowing us to
> pass in a foreground color (it simply uses black), but maybe that'll
> be better one day, and then this patch would make it easier for us to
> use the new features.
> 
> The fix looks more complicated than it is because it changes
> indentation (for the better) and removes a misleading comment.

Are we talking about the same "other fix"?  I was talking about the
one that uses Cairo calls directly.  Changes in indentation is not
what makes it more complex than the patch you suggested.

Message #71 received at 36315 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Tue, 02 Jul 2019 18:46:28 +0900

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 <at> math.s.chiba-u.ac.jp>
> > Cc: pipcet <at> gmail.com,
> > 	36315 <at> 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 <at> math.s.chiba-u.ac.jp

Message #74 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 36315 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Tue, 02 Jul 2019 17:26:11 +0300

> Date: Tue, 02 Jul 2019 18:46:28 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: 	pipcet <at> gmail.com,
> 	36315 <at> debbugs.gnu.org
> 
> > > > 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.

We clearly disagree, and I already said I didn't think this is worth
an argument.  Feel free to do whatever you see fit.

Message #77 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36315 <at> debbugs.gnu.org, pipcet <at> gmail.com,
 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Fri, 21 Aug 2020 15:04:22 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> 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.
>
> We clearly disagree, and I already said I didn't think this is worth
> an argument.  Feel free to do whatever you see fit.

As I understand this thread, moving to Cairo for SVG images fixes at
least two problems: The transparency issue, and it also allows us to
scale SVGs, both of which seem like nice additions.

There were a number of proposed patches in this thread -- which one is
the one that we should apply here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #80 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36315 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Fri, 21 Aug 2020 17:04:57 +0200 (CEST)

On Fri, Aug 21, 2020 at 03:04:22PM +0200, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> 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.
> >
> > We clearly disagree, and I already said I didn't think this is worth
> > an argument.  Feel free to do whatever you see fit.
> 
> As I understand this thread, moving to Cairo for SVG images fixes at
> least two problems: The transparency issue, and it also allows us to
> scale SVGs, both of which seem like nice additions.
> 
> There were a number of proposed patches in this thread -- which one is
> the one that we should apply here?

Possibly one from bug#40845... ;)

Although the one I provided there still needs work on the image cache.
-- 
Alan Third

Message #83 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alan Third <alan <at> idiocy.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36315 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Sat, 22 Aug 2020 15:29:05 +0200

Alan Third <alan <at> idiocy.org> writes:

>> There were a number of proposed patches in this thread -- which one is
>> the one that we should apply here?
>
> Possibly one from bug#40845... ;)

So many patches!

> Although the one I provided there still needs work on the image cache.

Is that much work?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #86 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 36315 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#36315: 27.0.50; SVG transparency handling is inaccurate
Date: Sat, 22 Aug 2020 18:00:01 +0200 (CEST)

On Sat, Aug 22, 2020 at 03:29:05PM +0200, Lars Ingebrigtsen wrote:
> Alan Third <alan <at> idiocy.org> writes:
> 
> >> There were a number of proposed patches in this thread -- which one is
> >> the one that we should apply here?
> >
> > Possibly one from bug#40845... ;)
> 
> So many patches!
> 
> > Although the one I provided there still needs work on the image cache.
> 
> Is that much work?  :-)

Actually, I think I made a mistake, this is another issue.

On the plus side, it inspired me to finish off the patch for 40845. :)
-- 
Alan Third

Message #89 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Qiantan Hong <qhong <at> mit.edu>
To: "36315 <at> debbugs.gnu.org" <36315 <at> debbugs.gnu.org>
Subject: Incorrect SVG color
Date: Fri, 18 Dec 2020 00:49:23 +0000

[Message part 1 (text/plain, inline)]

Is there any update on this bug?
The current behavior is unacceptable when the SVG color
is supposed to be the same as some color in Emacs
(in my case, I’m using SVG to build some UI elements),
The following code

(require 'svg)

(defun make-image (color)
  (let ((svg (svg-create 100 100)))
    (svg-rectangle svg 0 0 100 100 :fill color)
    (svg-image svg)))

(set-frame-parameter (window-frame) 'background-color “#f00000")

(insert (propertize " " 'display (make-image "#f00000")))

produce very notable color difference.

[signature.asc (application/pgp-signature, attachment)]

Message #92 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Qiantan Hong <qhong <at> mit.edu>
Cc: "36315 <at> debbugs.gnu.org" <36315 <at> debbugs.gnu.org>
Subject: Re: bug#36315: Incorrect SVG color
Date: Fri, 18 Dec 2020 15:00:34 +0000

On Fri, Dec 18, 2020 at 12:49:23AM +0000, Qiantan Hong wrote:
> Is there any update on this bug?
> The current behavior is unacceptable when the SVG color
> is supposed to be the same as some color in Emacs
> (in my case, I’m using SVG to build some UI elements),
> The following code
> 
> (require 'svg)
> 
> (defun make-image (color)
>   (let ((svg (svg-create 100 100)))
>     (svg-rectangle svg 0 0 100 100 :fill color)
>     (svg-image svg)))
> 
> (set-frame-parameter (window-frame) 'background-color “#f00000")
> 
> (insert (propertize " " 'display (make-image "#f00000")))
> 
> produce very notable color difference.

I can no longer replicate this on the master branch on macOS. We've
out-sourced colour handling fully to librsvg now, so that may make the
difference?

Either that or macOS is doing something unusual with colours, which I
wouldn't rule out.
-- 
Alan Third

Message #95 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Qiantan Hong <qhong <at> mit.edu>
To: Alan Third <alan <at> idiocy.org>
Cc: "36315 <at> debbugs.gnu.org" <36315 <at> debbugs.gnu.org>
Subject: Re: bug#36315: Incorrect SVG color
Date: Fri, 18 Dec 2020 15:47:32 +0000

[Message part 1 (text/plain, inline)]

I started to SEGFAULT when building from master branch
on macOS some time ago and now I’m doing
$ brew install emacs-plus —fetch-HEAD —with-xwidgets
The problem is there for me.
M-x emacs-version:
GNU Emacs 27.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G6032)) of 2020-12-18

> On Dec 18, 2020, at 10:00 AM, Alan Third <alan <at> idiocy.org> wrote:
> 
> On Fri, Dec 18, 2020 at 12:49:23AM +0000, Qiantan Hong wrote:
>> Is there any update on this bug?
>> The current behavior is unacceptable when the SVG color
>> is supposed to be the same as some color in Emacs
>> (in my case, I’m using SVG to build some UI elements),
>> The following code
>> 
>> (require 'svg)
>> 
>> (defun make-image (color)
>>  (let ((svg (svg-create 100 100)))
>>    (svg-rectangle svg 0 0 100 100 :fill color)
>>    (svg-image svg)))
>> 
>> (set-frame-parameter (window-frame) 'background-color “#f00000")
>> 
>> (insert (propertize " " 'display (make-image "#f00000")))
>> 
>> produce very notable color difference.
> 
> I can no longer replicate this on the master branch on macOS. We've
> out-sourced colour handling fully to librsvg now, so that may make the
> difference?
> 
> Either that or macOS is doing something unusual with colours, which I
> wouldn't rule out.
> --
> Alan Third

[signature.asc (application/pgp-signature, attachment)]

Message #98 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Qiantan Hong <qhong <at> mit.edu>
To: Alan Third <alan <at> idiocy.org>
Cc: "36315 <at> debbugs.gnu.org" <36315 <at> debbugs.gnu.org>
Subject: Re: bug#36315: Incorrect SVG color
Date: Fri, 18 Dec 2020 15:51:15 +0000

[Message part 1 (text/plain, inline)]

I suspect it is some weird thing about macOS,
because now the SVG color is brighter instead of darker...

> On Dec 18, 2020, at 10:00 AM, Alan Third <alan <at> idiocy.org> wrote:
> 
> On Fri, Dec 18, 2020 at 12:49:23AM +0000, Qiantan Hong wrote:
>> Is there any update on this bug?
>> The current behavior is unacceptable when the SVG color
>> is supposed to be the same as some color in Emacs
>> (in my case, I’m using SVG to build some UI elements),
>> The following code
>> 
>> (require 'svg)
>> 
>> (defun make-image (color)
>>  (let ((svg (svg-create 100 100)))
>>    (svg-rectangle svg 0 0 100 100 :fill color)
>>    (svg-image svg)))
>> 
>> (set-frame-parameter (window-frame) 'background-color “#f00000")
>> 
>> (insert (propertize " " 'display (make-image "#f00000")))
>> 
>> produce very notable color difference.
> 
> I can no longer replicate this on the master branch on macOS. We've
> out-sourced colour handling fully to librsvg now, so that may make the
> difference?
> 
> Either that or macOS is doing something unusual with colours, which I
> wouldn't rule out.
> --
> Alan Third

[signature.asc (application/pgp-signature, attachment)]

Message #101 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Qiantan Hong <qhong <at> mit.edu>
To: Alan Third <alan <at> idiocy.org>
Cc: "36315 <at> debbugs.gnu.org" <36315 <at> debbugs.gnu.org>
Subject: Re: bug#36315: Incorrect SVG color
Date: Fri, 18 Dec 2020 16:42:03 +0000

[Message part 1 (text/plain, inline)]

I fixed my build and it behaves correctly on macOS
now.

M-x emacs-version
GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G6032)) of 2020-12-18

To make sure I understand it, did we start outsourcing color some point after 27.1?


> On Dec 18, 2020, at 10:00 AM, Alan Third <alan <at> idiocy.org> wrote:
> 
> On Fri, Dec 18, 2020 at 12:49:23AM +0000, Qiantan Hong wrote:
>> Is there any update on this bug?
>> The current behavior is unacceptable when the SVG color
>> is supposed to be the same as some color in Emacs
>> (in my case, I’m using SVG to build some UI elements),
>> The following code
>> 
>> (require 'svg)
>> 
>> (defun make-image (color)
>>  (let ((svg (svg-create 100 100)))
>>    (svg-rectangle svg 0 0 100 100 :fill color)
>>    (svg-image svg)))
>> 
>> (set-frame-parameter (window-frame) 'background-color “#f00000")
>> 
>> (insert (propertize " " 'display (make-image "#f00000")))
>> 
>> produce very notable color difference.
> 
> I can no longer replicate this on the master branch on macOS. We've
> out-sourced colour handling fully to librsvg now, so that may make the
> difference?
> 
> Either that or macOS is doing something unusual with colours, which I
> wouldn't rule out.
> --
> Alan Third

[signature.asc (application/pgp-signature, attachment)]

Message #106 received at 36315-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Qiantan Hong <qhong <at> mit.edu>
Cc: "36315 <at> debbugs.gnu.org" <36315-done <at> debbugs.gnu.org>
Subject: Re: bug#36315: Incorrect SVG color
Date: Fri, 18 Dec 2020 18:04:45 +0000

On Fri, Dec 18, 2020 at 04:42:03PM +0000, Qiantan Hong wrote:
> I fixed my build and it behaves correctly on macOS
> now.
> 
> M-x emacs-version
> GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G6032)) of 2020-12-18

Excellent! Thanks for letting us know.

> To make sure I understand it, did we start outsourcing color some point after 27.1?

We pass the foreground and background colours into librsvg, which
creates the bitmap image that's displayed, in a commit that's just a
few months old. It will appear in Emacs 28.

I don't expect the change to be included in Emacs 27 since it's a
fairly large change introducing a number of new features and any new
Emacs 27 releases will be primarily bug fixes.
-- 
Alan Third

Message #109 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: 36315 <at> debbugs.gnu.org
Subject: Re: bug#36315: Incorrect SVG color
Date: Fri, 18 Dec 2020 18:16:44 +0000

On Fri, Dec 18, 2020 at 06:04:45PM +0000, Alan Third wrote:
> On Fri, Dec 18, 2020 at 04:42:03PM +0000, Qiantan Hong wrote:
> > I fixed my build and it behaves correctly on macOS
> > now.
> > 
> > M-x emacs-version
> > GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G6032)) of 2020-12-18
> 
> Excellent! Thanks for letting us know.
> 
> > To make sure I understand it, did we start outsourcing color some point after 27.1?
> 
> We pass the foreground and background colours into librsvg, which
> creates the bitmap image that's displayed, in a commit that's just a
> few months old. It will appear in Emacs 28.
> 
> I don't expect the change to be included in Emacs 27 since it's a
> fairly large change introducing a number of new features and any new
> Emacs 27 releases will be primarily bug fixes.

In a fit of over-excitement I closed this without checking whether
it's still a problem outside of the NS port. Should I reopen it?
-- 
Alan Third

Message #112 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 36315 <at> debbugs.gnu.org
Subject: Re: bug#36315: Incorrect SVG color
Date: Sat, 19 Dec 2020 01:24:26 +0100

Alan Third <alan <at> idiocy.org> writes:

> In a fit of over-excitement I closed this without checking whether
> it's still a problem outside of the NS port. Should I reopen it?

I can't reproduce the problem with the current Emacs trunk on Debian,
either, so I think you've fixed it.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #119 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Matt Huszagh <huszaghmatt <at> gmail.com>
Cc: 36315 <at> debbugs.gnu.org
Subject: Re: bug#36315: Incorrect SVG color
Date: Mon, 11 Oct 2021 09:52:17 +0200

Matt Huszagh <huszaghmatt <at> gmail.com> writes:

>> I can't reproduce the problem with the current Emacs trunk on Debian,
>> either, so I think you've fixed it.  :-)
>
> I'm experiencing this issue as well. The colors rendered by Emacs and
> librsvg are close but not exactly the same and the difference is noticeable
> particularly when placed side by side. I don't know much about these
> things, but is it possible that librsvg and Emacs use different color depths?

What Emacs version are you still seeing the problem in?

Message #122 received at 36315 <at> debbugs.gnu.org (full text, mbox):

From: Matt Huszagh <huszaghmatt <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: , 36315 <at> debbugs.gnu.org
Subject: Re: bug#36315: Incorrect SVG color
Date: Mon, 11 Oct 2021 07:24:31 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> What Emacs version are you still seeing the problem in?

Ok, I apologize. I actually can't reproduce the issue either, though I
am noticing a color difference in certain other cases. I'll dig into
this more and create a new issue when I have a minimal example that can
reproduce it.

Matt

Previous Next

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