GNU bug report logs - #56182
28.1; Display of SVG file with transparent background is incorrect

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 56182 in the body.
You can then email your comments to 56182 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: Pascal Quesseveur <pquessev <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.1; Display of SVG file with transparent background is incorrect
Date: Fri, 24 Jun 2022 08:30:38 +0200

Frame background color is set to royalblue4. Display of splash.svg
shows a background which looks dark orange.

emacs -Q \
--eval="(setq initial-frame-alist (list (cons 'background-color
\"royalblue4\")))"

(display-about-screen)



In GNU Emacs 28.1 (build 2, x86_64-w64-mingw32)
 of 2022-04-21 built on AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19044
System Description: Microsoft Windows 10 Pro (v10.0.2009.19044.1766)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation
 --without-compress-install CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES
NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Important settings:
  value of $LANG: FRA
  locale-coding-system: cp1252

Major mode: Group

Minor modes in effect:
  gnus-topic-mode: t
  display-time-mode: t
  gnus-undo-mode: t
  shell-dirtrack-mode: t
  icomplete-mode: t
  auto-image-file-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
c:/Users/Public/emacs-site/lisp/bbdb/bbdb-vcard-export hides c:/Users/Public/emacs-site/lisp/utils/bbdb-vcard-export
c:/Users/Public/emacs-site/lisp/utils/wdired hides c:/Program Files/Emacs/emacs-28.1/share/emacs/28.1/lisp/wdired
c:/Users/Public/emacs-site/lisp/utils/ls-lisp hides c:/Program Files/Emacs/emacs-28.1/share/emacs/28.1/lisp/ls-lisp
c:/Users/Public/emacs-site/lisp/utils/iimage hides c:/Program Files/Emacs/emacs-28.1/share/emacs/28.1/lisp/iimage
c:/Users/Public/emacs-site/lisp/utils/calculator hides c:/Program Files/Emacs/emacs-28.1/share/emacs/28.1/lisp/calculator
c:/Users/Public/emacs-site/lisp/utils/table hides c:/Program Files/Emacs/emacs-28.1/share/emacs/28.1/lisp/textmodes/table
c:/Users/Public/emacs-site/lisp/remember/remember hides c:/Program Files/Emacs/emacs-28.1/share/emacs/28.1/lisp/textmodes/remember
c:/Users/Public/emacs-site/lisp/utils/rlogin hides c:/Program Files/Emacs/emacs-28.1/share/emacs/28.1/lisp/net/rlogin
c:/Users/Public/emacs-site/lisp/dictionary-1.8.7/dictionary hides c:/Program Files/Emacs/emacs-28.1/share/emacs/28.1/lisp/net/dictionary

Features:
(shadow warnings emacsbug gnus-fun org-element avl-tree generator
ol-eww eww xdg mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect
gnus-search eieio-opt speedbar ezimage dframe ol-docview doc-view
image-mode exif ol-bibtex ol-bbdb ol-w3m ol-doi org-link-doi org ob
ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-footnote org-src
ob-comint org-pcomplete org-list org-faces org-entities org-version
ob-emacs-lisp ob-core ob-eval org-table oc-basic bibtex ol org-keys oc
org-compat org-macs org-loaddefs find-func supercite regi canlock
cl-print help-fns radix-tree url-http url-gw url-auth url-queue
url-cache shr-color color flow-fill emms-info-libtag emms-player-vlc
emms-player-mpv emms-player-mplayer emms-playlist-limit emms-volume
emms-volume-mixerctl emms-volume-pulse emms-volume-amixer emms-i18n
emms-stream-info emms-mode-line-icon emms-playlist-sort
emms-last-played emms-playing-time emms-player-simple emms-streams
emms-show-all emms-tag-editor emms-mark emms-mode-line
emms-info-ogginfo emms-info-mp3info emms-info later-do
emms-playlist-mode emms-source-playlist emms-source-file locate
music-list music-album emms-setup emms emms-compat mule-util sort
smerge-mode diff diff-mode jka-compr smiley gnus-cite mm-archive
gnus-async gnus-bcklg qp gnus-ml gnus-topic nndraft nnmh gnus-agent
gnus-srvr gnus-score score-mode nnvirtual gnus-msg nnml utf-7 gnutls
nnfolder cl-extra help-mode gnus-cache time-stamp network-stream nsm
nntp time highlight-current-line color-theme smtpmail sendmail
tumblesocks tumblesocks-view tumblesocks-compose markdown-mode
noutline outline htmlize tumblesocks-user tumblesocks-api oauth sasl
sasl-anonymous sasl-login sasl-plain hex-util hmac-sha1 plantuml-mode
pcase dash thingatpt html2help footnote rx muse-odf muse-xml muse-help
muse-bbcode muse-blosxom muse-wiki muse-texinfo texnfo-upd texinfo
texinfo-loaddefs muse-latex muse-html muse-docbook muse-xml-common
cus-edit pp cus-load muse-publish muse-project muse-protocols info
muse-regexps muse muse-nested-tags muse-mode u-vm-color
org-import-icalendar icalendar diary-lib diary-loaddefs bbdb-gnus
gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum shr
kinsoku svg dom browse-url gnus-group gnus-undo gnus-start gnus-dbus
dbus xml gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo
gnus-spec gnus-int gnus-range gnus-win gnus nnheader bbdb-snarf
mail-extr bbdb-com message rmc puny dired-explore dired-sort-menu
wid-edit acid dired-arc file-op dired-x dired dired-loaddefs rfc822
mml mml-sec gnus-util rmail rmail-loaddefs mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr mailabbrev mail-utils gmm-utils mailheader
bbdb-vcard-export bbdb-export bbdb-autoloads bbdb timezone tramp
tramp-loaddefs trampver tramp-integration files-x tramp-compat shell
pcomplete parse-time iso8601 time-date format-spec which idb gud
easy-mmode compile text-property-search comint ansi-color ring
qproj-opascal jsee javadoc-lookup ido jserial jswat qproj-java jdok
tempo url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util url-parse auth-source eieio eieio-core
eieio-loaddefs password-cache json subr-x map seq byte-opt bytecomp
byte-compile cconv url-vars mailcap xml-parse doxymacs qproj-cpp qproj
server dos-indent generic generic-x cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs lunar solar
cal-dst cal-tex cal-iso cal-menu calendar cal-loaddefs epa-file epa
derived epg rfc6068 epg-config ps-mule ipp cl-seq cl-macs cl gv
printing ps-print ps-print-loaddefs ps-def lpr icomplete advice
image-file image-converter edmacro kmacro cl-loaddefs cl-lib
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads
w32notify w32 lcms2 multi-tty make-network-process native-compile
emacs)

Memory information:
((conses 16 714525 66517)
 (symbols 48 40777 14)
 (strings 32 201864 7603)
 (string-bytes 1 6805914)
 (vectors 16 63072)
 (vector-slots 8 1026455 70244)
 (floats 8 1284 406)
 (intervals 56 3081 357)
 (buffers 992 36))

-- 
Pascal Quesseveur

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Pascal Quesseveur <pquessev <at> gmail.com>
Cc: 56182 <at> debbugs.gnu.org
Subject: Re: bug#56182: 28.1; Display of SVG file with transparent
 background is incorrect
Date: Fri, 24 Jun 2022 11:23:01 +0200

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

Pascal Quesseveur <pquessev <at> gmail.com> writes:

> Frame background color is set to royalblue4. Display of splash.svg
> shows a background which looks dark orange.
>
> emacs -Q \
> --eval="(setq initial-frame-alist (list (cons 'background-color
> \"royalblue4\")))"
>
> (display-about-screen)

I'm unable to reproduce this problem on Debian/bookworm, so it sounds
like it might be Windows/svg library version dependent:

[Message part 2 (image/png, inline)]

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

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

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

From: Pascal Quesseveur <pquessev <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#56182: 28.1; Display of SVG file with transparent
 background is incorrect
Date: Fri, 24 Jun 2022 14:18:55 +0200

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

>"LI" == Lars Ingebrigtsen <larsi <at> gnus.org> writes:

  LI> I'm unable to reproduce this problem on Debian/bookworm, so it sounds
  LI> like it might be Windows/svg library version dependent:

  I tried to replace librsvg by librsvg from version 27.1 and it
doesn't work either. Version 27.1 works fine.

  I also tried on another computer running a different versions of
windows, and it doesn't work.

[2022_06_24.png (image/png, attachment)]

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

-- 
Pascal Quesseveur
pquessev <at> gmail.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Alan Third <alan <at> idiocy.org>
Cc: pquessev <at> gmail.com, 56182 <at> debbugs.gnu.org
Subject: Re: bug#56182: 28.1;
 Display of SVG file with transparent background is incorrect
Date: Sat, 25 Jun 2022 12:25:54 +0300

> Cc: 56182 <at> debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Fri, 24 Jun 2022 11:23:01 +0200
> 
> Pascal Quesseveur <pquessev <at> gmail.com> writes:
> 
> > Frame background color is set to royalblue4. Display of splash.svg
> > shows a background which looks dark orange.
> >
> > emacs -Q \
> > --eval="(setq initial-frame-alist (list (cons 'background-color
> > \"royalblue4\")))"
> >
> > (display-about-screen)
> 
> I'm unable to reproduce this problem on Debian/bookworm, so it sounds
> like it might be Windows/svg library version dependent:

Alan, any chance you could look into this?

If you cannot reproduce it, can you tell which factors affect the
background of SVG images in Emacs 28 in the above scenario?

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

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pquessev <at> gmail.com, Lars Ingebrigtsen <larsi <at> gnus.org>,
 56182 <at> debbugs.gnu.org
Subject: Re: bug#56182: 28.1; Display of SVG file with transparent background
 is incorrect
Date: Sat, 25 Jun 2022 17:32:34 +0100

On Sat, Jun 25, 2022 at 12:25:54PM +0300, Eli Zaretskii wrote:
> > Cc: 56182 <at> debbugs.gnu.org
> > From: Lars Ingebrigtsen <larsi <at> gnus.org>
> > Date: Fri, 24 Jun 2022 11:23:01 +0200
> > 
> > Pascal Quesseveur <pquessev <at> gmail.com> writes:
> > 
> > > Frame background color is set to royalblue4. Display of splash.svg
> > > shows a background which looks dark orange.
> > >
> > > emacs -Q \
> > > --eval="(setq initial-frame-alist (list (cons 'background-color
> > > \"royalblue4\")))"
> > >
> > > (display-about-screen)
> > 
> > I'm unable to reproduce this problem on Debian/bookworm, so it sounds
> > like it might be Windows/svg library version dependent:
> 
> Alan, any chance you could look into this?
> 
> If you cannot reproduce it, can you tell which factors affect the
> background of SVG images in Emacs 28 in the above scenario?

I can't reproduce it.

An SVG can override the background colour, but splash.svg does not.

The background colour can be set directly using the :background image
spec.

If none of the above is true then the background is picked up from the
face defined in the "it" struct in xdisp.c where the image is defined.

If the face number is "-1" (which I suspect is only used for internal
usage in image.c, but you'll know better than me) then it uses the
default frame face.

Barring bugs, I don't think the version of librsvg should have any
effect on this as we set the background colour in the wrapper, which
as far as I'm aware will work on any SVG renderer.

I'm not sure if it's relevant, but in the screenshots provided by
Pascal some of the other face colours are different from what I see
here and what Lars has in his screenshot. It makes me wonder if
there's some other difference that's perhaps affecting this, although
I can't imagine what it could be.
-- 
Alan Third

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

From: Pascal Quesseveur <pquessev <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 56182 <at> debbugs.gnu.org
Subject: Re: bug#56182: 28.1; Display of SVG file with transparent
 background is incorrect
Date: Mon, 27 Jun 2022 08:49:26 +0200

Hello,

I installed the same version on another computer running W10, and
there is no problem with SVG background color. I cannot access the
computer on which the display was not good today. I'll take a closer
look at what differs between the installations tomorrow.


-- 
Pascal Quesseveur
pquessev <at> gmail.com

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

From: Pascal Quesseveur <pquessev <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 56182 <at> debbugs.gnu.org
Subject: Re: bug#56182: 28.1; Display of SVG file with transparent
 background is incorrect
Date: Mon, 27 Jun 2022 10:12:06 +0200

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

Hello,

I'm really sorry but my last email was wrong: the problem still exists
on this computer. I hadn't noticed that the runemacs command was
actually activating version 27.1. Here is the result with version
28.1.

[emacs-2022_06_27_01.png (image/png, attachment)]

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

-- 
Pascal Quesseveur
pquessev <at> gmail.com

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

From: Pascal Quesseveur <pquessev <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 56182 <at> debbugs.gnu.org
Subject: Re: bug#56182: 28.1; Display of SVG file with transparent
 background is incorrect
Date: Tue, 28 Jun 2022 20:38:11 +0200

>"AT" == Alan Third <alan <at> idiocy.org> a écrit :

  AT> I can't reproduce it.

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. For what it's worth I managed
to work around the problem in lisp. With version 27.1 I had
implemented an advice to improve the taking into account of the
background color in the style of SVG file. So I extended that advice
to solve my problem.

(defun qsr/create-image (orig-fun file-or-data &optional type data-p &rest props)
  "Advice around create-image. When image type is SVG, look for a
background color in SVG style and define this color as background
property in returned image.

When emacs 28 on Windows correct background color."
  (let ((data-format
         (and data-p (or (plist-get props :format) t))))
    (setq type (ignore-error unknown-image-type
                 (image-type file-or-data type data-format)))
    (let ((image (apply orig-fun file-or-data type data-p props))
          color)
      (when image
        ;; Regexp to match
        ;; <svg xmlns="http://www" style="width:566px;background:#dddddd;"
        ;; or
        ;; <style ..>...background-color::#dddddd;...</style>
        (if (and (eq type 'svg) data-p
                 (or (string-match
                      "<svg[^>]*\\<style=\"[^\"]*\\<background[^:]*:\\([^;]*\\);"
                      file-or-data)
                     (string-match
                      "<style[^<]*background-color: *\\([^;]*\\);"
                      file-or-data)))
            (setq color (match-string 1 file-or-data))
          ;; No color defined in svg element, use default background.
          (setq color (face-attribute 'default :background))
          (when (and (= emacs-major-version 28)
                     (eq system-type 'windows-nt))
            ;; When emacs 28 transform color.
            (let ((crgb (color-values color))
                  (gamma (frame-parameter nil 'screen-gamma)))
              (when crgb
                (let ((r (elt crgb 0))
                      (g (elt crgb 1))
                      (b (elt crgb 2)))
                  ;; If screen gamma correction is defined in frame
                  ;; parameters, inverse gamma correction.
                  (when gamma
                    (let ((invgc (* gamma 0.45445)))
                      ;; are r g b always 2 bytes?
                      (setq r (* (expt (/ r 65535.0) invgc) 65535.0)
                            g (* (expt (/ g 65535.0) invgc) 65535.0)
                            b (* (expt (/ b 65535.0) invgc) 65535.0))))
                  ;; color is defined as BGR.
                  (setq color (format "#%4X%4X%4X" b g r)))
                )))
          )
        (setq image (nconc image (list :background color))))
      image)))
    
(advice-add 'create-image :around #'qsr/create-image)


-- 
Pascal Quesseveur
pquessev <at> gmail.com

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

From: Alan Third <alan <at> idiocy.org>
To: Pascal Quesseveur <pquessev <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 56182 <at> debbugs.gnu.org
Subject: Re: bug#56182: 28.1; Display of SVG file with transparent background
 is incorrect
Date: Tue, 28 Jun 2022 20:45:17 +0100

On Tue, Jun 28, 2022 at 08:38:11PM +0200, Pascal Quesseveur wrote:
> >"AT" == Alan Third <alan <at> idiocy.org> a écrit :
> 
>   AT> I can't reproduce it.
> 
> 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.

Can you try using describe-face to compare the face where the image is
and another place where the background colour is shown correctly?


> 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. For what it's worth I managed
> to work around the problem in lisp. With version 27.1 I had
> implemented an advice to improve the taking into account of the
> background color in the style of SVG file. So I extended that advice
> to solve my problem.

*scratches head*

Eli, do we need to decode the "unsigned long" colours in a special way
on Windows? It could be I've missed a vital step and am using them
incorrectly. So if the colour is defined in BGR byte order, and I then
use the unsigned long directly in a printf("#%06X", colour) style,
that's likely to be wrong, yes?

-- 
Alan Third

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: pquessev <at> gmail.com, larsi <at> gnus.org, 56182 <at> debbugs.gnu.org
Subject: Re: bug#56182: 28.1; Display of SVG file with transparent background
 is incorrect
Date: Wed, 29 Jun 2022 05:26:48 +0300

> Date: Tue, 28 Jun 2022 20:45:17 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
> 	56182 <at> debbugs.gnu.org
> 
> > 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. For what it's worth I managed
> > to work around the problem in lisp. With version 27.1 I had
> > implemented an advice to improve the taking into account of the
> > background color in the style of SVG file. So I extended that advice
> > to solve my problem.
> 
> *scratches head*
> 
> Eli, do we need to decode the "unsigned long" colours in a special way
> on Windows? It could be I've missed a vital step and am using them
> incorrectly. So if the colour is defined in BGR byte order, and I then
> use the unsigned long directly in a printf("#%06X", colour) style,
> that's likely to be wrong, yes?

I don't think I understand what colors you had in mind here.  Can you
walk me through the relevant code?  I'm not sure I will have an
answer, but I could at least try things.

Thanks.

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

From: Alan Third <alan <at> idiocy.org>
To: Pascal Quesseveur <pquessev <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 56182 <at> debbugs.gnu.org
Subject: Re: bug#56182: 28.1; Display of SVG file with transparent background
 is incorrect
Date: Sat, 9 Sep 2023 13:09:44 +0100

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

-- 
Alan Third

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

From: Alan Third <alan <at> idiocy.org>
To: Pascal Quesseveur <pquessev <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
 Lars Ingebrigtsen <larsi <at> gnus.org>, 56182 <at> debbugs.gnu.org
Subject: Re: bug#56182: 28.1; Display of SVG file with transparent background
 is incorrect
Date: Mon, 11 Sep 2023 20:10:24 +0100

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

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

[0001-Fix-SVG-colors-bug-56182.patch (text/x-diff, attachment)]

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

From: Corwin Brust <corwin <at> bru.st>
To: Alan Third <alan <at> idiocy.org>, Pascal Quesseveur <pquessev <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 
 Lars Ingebrigtsen <larsi <at> gnus.org>, 56182 <at> debbugs.gnu.org
Subject: Re: bug#56182: 28.1; Display of SVG file with transparent background
 is incorrect
Date: Tue, 12 Sep 2023 08:55:37 -0500

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

On Mon, Sep 11, 2023 at 2:10 PM Alan Third <alan <at> idiocy.org> wrote:
>
> 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.
>

Compile: yes.  Fixes the problem: unsure.

I did not have difficulty building the emacs-29 branch with this patch
applied. Unfortunately, I could not confirm (or disprove) the success
of the patch because I received (under -Q) "Invalid Image
Specification" trying to load etc/images/down.svg.  Here's a
screenshot:

https://bru.st/i/emacs-29.1.50.1_i9DY4oaggq.png

I then confirmed I get this same from a recent (upatched:
ca95e45f7e828aebdf2736c9c7b2d64f9621214e) build from the development
branch.  Others I grabbed at random also give this error now, so I'm
confident it's nothing to do with down.svg.  An unpatched emacs-28
build could display SVGs, I remember that 29.1 can but didn't check.
Is it possible there's a recent regression breaking SVG image display
more generally (perhaps merged up, already)?

Are there things you can think of which I might be doing incorrectly?
I can't think of them.

This was a perfectly clean clone, checkout at emacs-29, patch applied
cleanly, I noticed only the below couple of warnings in the build log,
but perhaps I've missed something so the full output from
autogen+configure and from make are attached.

w32heap.c:853:14: warning: 'm' may be used uninitialized [-Wmaybe-uninitialized]
mml1991.el:140:16: Warning: the function `mm-disable-multibyte' might
not be defined at runtime.

I'm assuming bisection may be appreciated but I'll wait for
confirmation before trying.  In theory, I have an excellent setup for
this but I haven't tried it in anger yet.

Should I open a seperate bug report?

> --
> Alan Third

[emacs-29-configure.log (application/octet-stream, attachment)]

[emacs-29-make.log (application/octet-stream, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: pquessev <at> gmail.com, larsi <at> gnus.org, 56182 <at> debbugs.gnu.org
Subject: Re: bug#56182: 28.1; Display of SVG file with transparent background
 is incorrect
Date: Tue, 12 Sep 2023 17:19:01 +0300

> Date: Mon, 11 Sep 2023 20:10:24 +0100
> From: Alan Third <alan <at> idiocy.org>
> 
> 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.

Thanks, the patch builds fine on MS-Windows, and it solves the
problem, including the recipe in the original message that started
this bug.

Please install on the emacs-29 branch, and thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Corwin Brust <corwin <at> bru.st>
Cc: pquessev <at> gmail.com, alan <at> idiocy.org, larsi <at> gnus.org, 56182 <at> debbugs.gnu.org
Subject: Re: bug#56182: 28.1; Display of SVG file with transparent background
 is incorrect
Date: Tue, 12 Sep 2023 17:22:21 +0300

> From: Corwin Brust <corwin <at> bru.st>
> Date: Tue, 12 Sep 2023 08:55:37 -0500
> 
> Compile: yes.  Fixes the problem: unsure.
> 
> I did not have difficulty building the emacs-29 branch with this patch
> applied. Unfortunately, I could not confirm (or disprove) the success
> of the patch because I received (under -Q) "Invalid Image
> Specification" trying to load etc/images/down.svg.  Here's a
> screenshot:
> 
> https://bru.st/i/emacs-29.1.50.1_i9DY4oaggq.png
> 
> I then confirmed I get this same from a recent (upatched:
> ca95e45f7e828aebdf2736c9c7b2d64f9621214e) build from the development
> branch.  Others I grabbed at random also give this error now, so I'm
> confident it's nothing to do with down.svg.  An unpatched emacs-28
> build could display SVGs, I remember that 29.1 can but didn't check.
> Is it possible there's a recent regression breaking SVG image display
> more generally (perhaps merged up, already)?

I see no problems with SVG images here, but my librsvg is quite old,
so maybe the regression happened in parts that are not compiled with
my librsvg.

> Should I open a seperate bug report?

Yes, please.

Thanks.

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

From: Corwin Brust <corwin <at> bru.st>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pquessev <at> gmail.com, alan <at> idiocy.org, larsi <at> gnus.org, 56182 <at> debbugs.gnu.org
Subject: Re: bug#56182: 28.1; Display of SVG file with transparent background
 is incorrect
Date: Tue, 12 Sep 2023 12:01:27 -0500

On Tue, Sep 12, 2023 at 9:22 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Corwin Brust <corwin <at> bru.st>
>
> I see no problems with SVG images here, but my librsvg is quite old,
> so maybe the regression happened in parts that are not compiled with
> my librsvg.
>
> > Should I open a seperate bug report?
>
> Yes, please.
>

I can no longer reproduce.  Current (brand new) builds from emacs-29
and master both display SVG images just fine.  I'm fascinated to
unravel what I did wrong.

Sorry for the noise.

>
> Thanks.
>

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

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pquessev <at> gmail.com, larsi <at> gnus.org, 56182-done <at> debbugs.gnu.org
Subject: Re: bug#56182: 28.1; Display of SVG file with transparent background
 is incorrect
Date: Wed, 13 Sep 2023 20:21:24 +0100

On Tue, Sep 12, 2023 at 05:19:01PM +0300, Eli Zaretskii wrote:
> Thanks, the patch builds fine on MS-Windows, and it solves the
> problem, including the recipe in the original message that started
> this bug.
> 
> Please install on the emacs-29 branch, and thanks.

Thanks. I've pushed to emacs-29.
-- 
Alan Third

Previous Next

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