bug#56182: 28.1; Display of SVG file with transparent background is incorrect

[Alan Third <alan@idiocy.org>]

[-- Attachment #1: Type: text/plain, Size: 2127 bytes --]

On Sat, Sep 09, 2023 at 01:09:44PM +0100, Alan Third wrote:
> On Tue, Jun 28, 2022 at 08:38:11PM +0200, Pascal Quesseveur wrote:
> > From what I understand the way to deal with background transparency of
> > SVG images has changed in version 28.1 in function svg_load_image
> > (comments about opacity are still there but I think they are
> > irrelevant). Now the SVG image is encapsulated in another SVG image in
> > which a rect element is defined with the background color of the
> > image.
> > 
> > I don't know why it doesn't work on the W10 computers I work on. I
> > don't know if the problem comes from this modificatino either. It
> > seems to me that the displayed color is BGR instead of RGB and the
> > screen gamma correction is not applied.
> 
> Apologies for leaving this so long.
> 
> Is this an issue for *all* Windows machines? The documentation for
> COLORREF[1] suggests that Windows uses a byte format for *all* colours
> of 0x00BBGGRR, which would explain this, but I thought it worked fine
> on some machines?
> 
> Alternatively, I'm looking at the wrong documentation, however it
> appears the code in w32term.c uses this COLORREF for colours as
> defined in a face, so I think it's the right thing.
> 
> If this is right and Windows always uses this format, all we need to
> do is format the SVG colour differently on Windows.
> 
> [1] https://learn.microsoft.com/en-gb/windows/win32/gdi/colorref?redirectedfrom=MSDN

I've checked with the one Windows box I have available to me and it
looks like this is the same there, so I've attached a patch that I
hope will fix this. All it's doing is reversing bytes 1 and 3 (from
the right) of the colours, so when it's used in the SVG code it should
display correctly.

I can't check it as I don't have a Windows development box. If someone
can confirm that this 1. compiles and 2. fixes the problem that would
be great.

I found it easy to check by setting the theme to "light blue" and
loading etc/images/down.svg. The correct result should have a black
triangle on a blue background, but incorrect is a black triangle on a
yellow background.
-- 
Alan Third

[-- Attachment #2: 0001-Fix-SVG-colors-bug-56182.patch --]
[-- Type: text/x-diff, Size: 1133 bytes --]

From 94649915ac108fb88b30f5ffda4606c4a1166289 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Mon, 11 Sep 2023 19:58:14 +0100
Subject: [PATCH] Fix SVG colors (bug#56182)

* src/image.c (svg_load_image): Reverse the R and B bytes in the
Windows colors before using them to generate the SVG.
---
 src/image.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/src/image.c b/src/image.c
index a4b8d21cee6..84db9bfb3b8 100644
--- a/src/image.c
+++ b/src/image.c
@@ -12075,6 +12075,18 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
         img->background_valid = 1;
       }
 
+#if HAVE_NTGUI
+    /* Windows stores the image colours in BGR format, and SVG expects
+       them in RGB.  */
+    foreground = (foreground & 0x0000FF) << 16
+      | (foreground & 0xFF0000) >> 16
+      | (foreground & 0x00FF00);
+
+    background = (background & 0x0000FF) << 16
+      | (background & 0xFF0000) >> 16
+      | (background & 0x00FF00);
+#endif
+
     wrapped_contents = xmalloc (buffer_size);
 
     if (buffer_size <= snprintf (wrapped_contents, buffer_size, wrapper,
-- 
2.40.1