bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Stefan Kangas]

Severity: wishlist

In M-x customize, we use the etc/images/{un,}checked.xpm and other
icons. These images do not scale when you increase the font, and (this
is subjective but) generally don't look too good.

I think we could get better result if we used Unicode characters like:

- ☑ checked
- ☐ unchecked
- ▼ or ▾ down triangle
- ▶ or ▸ right triangle

I'm less sure about the look of these but they do exist:

- ⬤ or ◉ or 🔘 radio button selected (the last one was added to Unicode
  in 2015 and gives the hex square here)
- ◯ radio button unselected

Obviously how these look depends on the fonts you have installed.  On my
machine, the "Fira Code" font is used, which makes them look very good.
(They also obviously scale when increasing the font size.)

Perhaps we could prefer Unicode icons if they are available, and fall
back on icons if not.  It seems like we can use `char-displayable-p' to
see if there is any font that can display that codepoint.

If we don't think that will produce consistently improved results, we
could also just add a new option to use Unicode characters.

Thoughts?

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Lars Ingebrigtsen]

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

Stefan Kangas <stefan@marxist.se> writes:

> I'm less sure about the look of these but they do exist:
>
> - ⬤ or ◉ or 🔘 radio button selected (the last one was added to Unicode
>   in 2015 and gives the hex square here)
> - ◯ radio button unselected

These look like this here:


[-- Attachment #2: Type: image/png, Size: 17190 bytes --]

[-- Attachment #3: Type: text/plain, Size: 280 bytes --]


> If we don't think that will produce consistently improved results, we
> could also just add a new option to use Unicode characters.
>
> Thoughts?

I think it's a good idea.

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

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> I'm less sure about the look of these but they do exist:
>>
>> - ⬤ or ◉ or 🔘 radio button selected (the last one was added to Unicode
>>   in 2015 and gives the hex square here)
>> - ◯ radio button unselected
>
> These look like this here:

◉ seems to pair well with ◯ here too.  So perhaps that could be a
reasonable choice for the radio buttons.

The 🔘 character is fancy, but I don't know what to use for the
non-selected version (and it doesn't display here, so...).

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 11 Mar 2021 18:01:06 +0100
> Cc: 47074@debbugs.gnu.org
> 
> > - ⬤ or ◉ or 🔘 radio button selected (the last one was added to Unicode
> >   in 2015 and gives the hex square here)
> > - ◯ radio button unselected
> 
> These look like this here:

With Symbola as the font (which is what we have by default), the
result is much worse than images.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> With Symbola as the font (which is what we have by default), the
> result is much worse than images.

:-/

So I guess using Unicode would need to be optional.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 11 Mar 2021 11:51:40 -0600
> Cc: 47074@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > With Symbola as the font (which is what we have by default), the
> > result is much worse than images.
> 
> :-/
> 
> So I guess using Unicode would need to be optional.

Yes, I think so.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 11 Mar 2021 10:51:19 -0600
> 
> Obviously how these look depends on the fonts you have installed.  On my
> machine, the "Fira Code" font is used, which makes them look very good.

Exactly, so depending on a font to produce good results is not
necessarily a good idea.

> Perhaps we could prefer Unicode icons if they are available, and fall
> back on icons if not.  It seems like we can use `char-displayable-p' to
> see if there is any font that can display that codepoint.

char-displayable-p is expensive, though.  And it does nothing against
the not-so-pretty fonts, of course

So I generally find the idea of using characters for this purpose
problematic; we've seen these problems in other places in Emacs.  Why
not use SVG images instead?

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> char-displayable-p is expensive, though.

Could we perhaps cache the results if it is prohibitively slow?

> And it does nothing against the not-so-pretty fonts, of course

This is the bigger problem indeed.

> So I generally find the idea of using characters for this purpose
> problematic; we've seen these problems in other places in Emacs.  Why
> not use SVG images instead?

I think SVG is obviously much preferable to XPM, but there is still the
problem that the images don't scale with the text.  Do we have a general
solution to that?  If not, should we have one?

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> I think SVG is obviously much preferable to XPM, but there is still the
> problem that the images don't scale with the text.  Do we have a general
> solution to that?  If not, should we have one?

`create-image' does scale the images with the text (by default -- but
perhaps not on all platforms) -- it looks at how big the default font is
and sets :scaling.

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

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  47074@debbugs.gnu.org
> Date: Thu, 11 Mar 2021 19:03:48 +0100
> 
> Stefan Kangas <stefan@marxist.se> writes:
> 
> > I think SVG is obviously much preferable to XPM, but there is still the
> > problem that the images don't scale with the text.  Do we have a general
> > solution to that?  If not, should we have one?
> 
> `create-image' does scale the images with the text (by default -- but
> perhaps not on all platforms) -- it looks at how big the default font is
> and sets :scaling.

But that doesn't happen in Custom buffers when one enlarges the text
scale, does it?

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> `create-image' does scale the images with the text (by default -- but
>> perhaps not on all platforms) -- it looks at how big the default font is
>> and sets :scaling.
>
> But that doesn't happen in Custom buffers when one enlarges the text
> scale, does it?

Oh, I wasn't thinking about `C-x +' and friends.  No, the images are not
re-scaled by that command.  (Of course, that's something we could decide
to do, though.)

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

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Oh, I wasn't thinking about `C-x +' and friends.  No, the images are not
> re-scaled by that command.  (Of course, that's something we could decide
> to do, though.)

I think we should do precisely that.  Perhaps one should be able to turn
it off, as it might not always make sense (e.g. in eww buffers?).

How would we go about implementing something like that?  Do we need to
scan the buffer for any images and re-insert them when we change the
font size, or can we just add an image attribute or something?

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Oh, I wasn't thinking about `C-x +' and friends.  No, the images are not
>> re-scaled by that command.  (Of course, that's something we could decide
>> to do, though.)
>
> I think we should do precisely that.  Perhaps one should be able to turn
> it off, as it might not always make sense (e.g. in eww buffers?).

I think it would make sense in eww buffers, too...  probably.  If there
are buffers where this shouldn't happen, we can add a mechanism for
that, though.

> How would we go about implementing something like that?  Do we need to
> scan the buffer for any images and re-insert them when we change the
> font size, or can we just add an image attribute or something?

I think just altering the :scale image attribute would probably do the
trick...  but we can't destructively modify the image objects, I guess,
so re-inserting them is probably necessary...

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

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think just altering the :scale image attribute would probably do the
> trick...  but we can't destructively modify the image objects, I guess,
> so re-inserting them is probably necessary...

So basically `text-scale-adjust' should search the buffer for any images
and re-insert them with the new size?

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> I think just altering the :scale image attribute would probably do the
>> trick...  but we can't destructively modify the image objects, I guess,
>> so re-inserting them is probably necessary...
>
> So basically `text-scale-adjust' should search the buffer for any images
> and re-insert them with the new size?

Yes, I think so.  I haven't actually tried this, but I think it should
be possible...

If the images are large, then this may be slow, but it shouldn't
generate a lot of garbage (since the image data itself in (in case of a
"data" image) should be shared, still.  I think it's worth a try, at
least.  If it turns out to be very slow, then we can start thinking
about mechanisms for marking specific (smaller) icons for rescaling,
while leaving the rest of the images alone.

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

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 11 Mar 2021 19:38:12 -0600
> Cc: 47074@debbugs.gnu.org
> 
> How would we go about implementing something like that?  Do we need to
> scan the buffer for any images and re-insert them when we change the
> font size, or can we just add an image attribute or something?

AFAIR, the display property has a way of reacting to the value of a
symbol's variable cell automatically.  Not sure the image display
property can, too, but it won't do any harm trying.  Keep in mind that
changing the text scale requires redisplaying the buffer, so Emacs
will regenerate the images anyway.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 11 Mar 2021 11:51:45 -0600
> Cc: 47074@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > char-displayable-p is expensive, though.
> 
> Could we perhaps cache the results if it is prohibitively slow?

It isn't prohibitively slow, just slow.

> > So I generally find the idea of using characters for this purpose
> > problematic; we've seen these problems in other places in Emacs.  Why
> > not use SVG images instead?
> 
> I think SVG is obviously much preferable to XPM, but there is still the
> problem that the images don't scale with the text.  Do we have a general
> solution to that?  If not, should we have one?

With SVG, I believe we could.  (We can scale other kinds of images as
well, but they don't look well when enlarged, AFAIK.)

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Alan Third]

On Thu, Mar 11, 2021 at 10:01:11PM +0200, Eli Zaretskii wrote:
> > 
> > I think SVG is obviously much preferable to XPM, but there is still the
> > problem that the images don't scale with the text.  Do we have a general
> > solution to that?  If not, should we have one?
> 
> With SVG, I believe we could.  (We can scale other kinds of images as
> well, but they don't look well when enlarged, AFAIK.)

I've been thinking about this, and assuming we can extract the font
name and size from the face in C then we can create a default CSS
stylesheet that should make 1em in an SVG equivalent to the actual
Emacs font height.

It might mean rewriting the code I recently rewrote to extract the
foreground and background colours to just reference the face id, but
that will probably result in even less good image caching than we have
at the moment.

In fact, it's possible to build an SVG within Emacs that contains the
correct font details that will display at the correct size.

Something like this:

(require 'svg)
(let* ((scale (cadr (assoc :height (assoc 'default face-remapping-alist))))
       (height (* (/ (face-attribute 'default :height) 10) (if scale scale 1)))
       (family (face-attribute 'default :family))
       (img (svg-create height height
			:font-size height
			:font-family family)))
  (svg-circle img "0.5em" "0.5em" "0.5em")
  (insert "XX")
  (insert-image (svg-image img :ascent 'center))
  (insert "XX"))

Alas it doesn't resize the image as you scale with C-x C-+.

Perhaps there is some way to mark certain SVGs as part of the UI and
regenerate them?

Yet another alternative is to define a different text property (or
whatever) that only draws SVGs, but on the fly so there's no caching
and we can put them anywhere in the frame. But that might not be a
good idea.
-- 
Alan Third

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> In fact, it's possible to build an SVG within Emacs that contains the
> correct font details that will display at the correct size.
>
> Something like this:
>
> (require 'svg)
> (let* ((scale (cadr (assoc :height (assoc 'default face-remapping-alist))))
>        (height (* (/ (face-attribute 'default :height) 10) (if scale scale 1)))
>        (family (face-attribute 'default :family))
>        (img (svg-create height height
> 			:font-size height
> 			:font-family family)))
>   (svg-circle img "0.5em" "0.5em" "0.5em")
>   (insert "XX")
>   (insert-image (svg-image img :ascent 'center))
>   (insert "XX"))

Hm...  Isn't that basically what `image-compute-scaling-factor' does
already, only on the `create-image' level?

> Alas it doesn't resize the image as you scale with C-x C-+.
>
> Perhaps there is some way to mark certain SVGs as part of the UI and
> regenerate them?

Yes, doing so should be easy enough.

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

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Alan Third]

On Fri, Mar 12, 2021 at 01:12:02AM +0100, Lars Ingebrigtsen wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > In fact, it's possible to build an SVG within Emacs that contains the
> > correct font details that will display at the correct size.
> >
> > Something like this:
> >
> > (require 'svg)
> > (let* ((scale (cadr (assoc :height (assoc 'default face-remapping-alist))))
> >        (height (* (/ (face-attribute 'default :height) 10) (if scale scale 1)))
> >        (family (face-attribute 'default :family))
> >        (img (svg-create height height
> > 			:font-size height
> > 			:font-family family)))
> >   (svg-circle img "0.5em" "0.5em" "0.5em")
> >   (insert "XX")
> >   (insert-image (svg-image img :ascent 'center))
> >   (insert "XX"))
> 
> Hm...  Isn't that basically what `image-compute-scaling-factor' does
> already, only on the `create-image' level?

Sort of, although this should produce an image that's the exact same
size as the text, which I don't think we can duplicate without making
image-compute-scaling-factor resize much more aggressively. Nor would
we want to, generally.

-- 
Alan Third

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> Date: Thu, 11 Mar 2021 23:49:54 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Stefan Kangas <stefan@marxist.se>, 47074@debbugs.gnu.org
> 
> I've been thinking about this, and assuming we can extract the font
> name and size from the face in C then we can create a default CSS
> stylesheet that should make 1em in an SVG equivalent to the actual
> Emacs font height.

The font details can be accessed from Lisp as well, if that's more
convenient.

> Alas it doesn't resize the image as you scale with C-x C-+.

Why not? what is preventing that?

> Perhaps there is some way to mark certain SVGs as part of the UI and
> regenerate them?
> 
> Yet another alternative is to define a different text property (or
> whatever) that only draws SVGs, but on the fly so there's no caching
> and we can put them anywhere in the frame. But that might not be a
> good idea.

if these two paragraphs explain why the images currently don't resize
with the text scale, I don't think I follow the reasoning.  Please
elaborate.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Alan Third]

On Fri, Mar 12, 2021 at 09:27:01AM +0200, Eli Zaretskii wrote:
> > Date: Thu, 11 Mar 2021 23:49:54 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: Stefan Kangas <stefan@marxist.se>, 47074@debbugs.gnu.org
> > 
> > I've been thinking about this, and assuming we can extract the font
> > name and size from the face in C then we can create a default CSS
> > stylesheet that should make 1em in an SVG equivalent to the actual
> > Emacs font height.
> 
> The font details can be accessed from Lisp as well, if that's more
> convenient.

It depends. Doing it at the C level means it Just Works for all SVGs.
That is if you put unstyled text into any SVG it would appear with the
size and font of the surrounding face rather than whatever the librsvg
default setting is.

Doing it in lisp would require a little more care.

> > Alas it doesn't resize the image as you scale with C-x C-+.
> 
> Why not? what is preventing that?

Simply that we're inserting an image and to change it we'd have to
regenerate it. If it were being done as part of a mode (this bug
report is about customize, so in there I guess?) it should be possible
to make it fix it.

> > Perhaps there is some way to mark certain SVGs as part of the UI and
> > regenerate them?
> > 
> > Yet another alternative is to define a different text property (or
> > whatever) that only draws SVGs, but on the fly so there's no caching
> > and we can put them anywhere in the frame. But that might not be a
> > good idea.
> 
> if these two paragraphs explain why the images currently don't resize
> with the text scale, I don't think I follow the reasoning.  Please
> elaborate.

No, I was just listing off the different ways I could think of to make
SVGs appear more coupled to the text.
-- 
Alan Third

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> Date: Fri, 12 Mar 2021 18:25:34 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: stefan@marxist.se, 47074@debbugs.gnu.org
> 
> > > Alas it doesn't resize the image as you scale with C-x C-+.
> > 
> > Why not? what is preventing that?
> 
> Simply that we're inserting an image and to change it we'd have to
> regenerate it.

Even if some attributes of the image spec reference variables?

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Alan Third]

On Fri, Mar 12, 2021 at 08:37:40PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 12 Mar 2021 18:25:34 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: stefan@marxist.se, 47074@debbugs.gnu.org
> > 
> > > > Alas it doesn't resize the image as you scale with C-x C-+.
> > > 
> > > Why not? what is preventing that?
> > 
> > Simply that we're inserting an image and to change it we'd have to
> > regenerate it.
> 
> Even if some attributes of the image spec reference variables?

Yes, it's inserted into the buffer as a simple list, I believe, so
changing the variables doesn't affect the existing image spec.
-- 
Alan Third

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> Date: Fri, 12 Mar 2021 18:43:44 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: stefan@marxist.se, 47074@debbugs.gnu.org
> 
> > > Simply that we're inserting an image and to change it we'd have to
> > > regenerate it.
> > 
> > Even if some attributes of the image spec reference variables?
> 
> Yes, it's inserted into the buffer as a simple list, I believe, so
> changing the variables doesn't affect the existing image spec.

We could change that, though.  Like supporting :eval in the spec or
somesuch.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Stefan Kangas]

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

Alan Third <alan@idiocy.org> writes:

> On Thu, Mar 11, 2021 at 10:01:11PM +0200, Eli Zaretskii wrote:
>> >
>> > I think SVG is obviously much preferable to XPM, but there is still the
>> > problem that the images don't scale with the text.  Do we have a general
>> > solution to that?  If not, should we have one?
>>
>> With SVG, I believe we could.  (We can scale other kinds of images as
>> well, but they don't look well when enlarged, AFAIK.)
>
> I've been thinking about this, and assuming we can extract the font
> name and size from the face in C then we can create a default CSS
> stylesheet that should make 1em in an SVG equivalent to the actual
> Emacs font height.

I took a stab at adding SVG icons, as found in the GNOME Adwaita Icon
Theme.  I had to scrub some color details from the SVG files by hand,
but they now seem to automagically adapt to the :foreground and
:background of the current face (but I could be wrong about that as I
don't understand how this is supposed to work).

How would a patch like the attached relate to the changes you propose,
Alan?

[-- Attachment #2: 0001-Add-SVG-icons-for-customize-buffers.patch --]
[-- Type: text/x-diff, Size: 6394 bytes --]

From 25d8f2a7c136a991098ddefc89ff11d9af722377 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Sat, 13 Mar 2021 03:20:29 +0100
Subject: [PATCH] Add SVG icons for customize buffers

---
 etc/images/ui/README               | 18 ++++++++++++++++++
 etc/images/ui/checkbox-checked.svg |  6 ++++++
 etc/images/ui/checkbox-mixed.svg   |  6 ++++++
 etc/images/ui/checkbox.svg         |  3 +++
 etc/images/ui/radio-checked.svg    |  6 ++++++
 etc/images/ui/radio-mixed.svg      |  6 ++++++
 etc/images/ui/radio.svg            |  3 +++
 lisp/wid-edit.el                   | 10 +++++-----
 8 files changed, 53 insertions(+), 5 deletions(-)
 create mode 100644 etc/images/ui/README
 create mode 100644 etc/images/ui/checkbox-checked.svg
 create mode 100644 etc/images/ui/checkbox-mixed.svg
 create mode 100644 etc/images/ui/checkbox.svg
 create mode 100644 etc/images/ui/radio-checked.svg
 create mode 100644 etc/images/ui/radio-mixed.svg
 create mode 100644 etc/images/ui/radio.svg

diff --git a/etc/images/ui/README b/etc/images/ui/README
new file mode 100644
index 0000000000..f83843d34e
--- /dev/null
+++ b/etc/images/ui/README
@@ -0,0 +1,18 @@
+COPYRIGHT AND LICENSE INFORMATION FOR IMAGE FILES
+
+* The following icons are from the Adwaita Icon Theme (made by the
+GNOME project).  They are not part of Emacs, but are distributed and
+used by Emacs.  They are licensed under either the GNU LGPL v3 or the
+Creative Commons Attribution-Share Alike 3.0 United States License.
+
+To view a copy of the CC-BY-SA licence, visit
+http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative
+Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.
+
+For more information see the adwaita-icon-theme repository at:
+
+    https://gitlab.gnome.org/GNOME/adwaita-icon-theme
+
+Emacs images and their source in the Adwaita/scalable directory.
+
+ ... FIXME ...
diff --git a/etc/images/ui/checkbox-checked.svg b/etc/images/ui/checkbox-checked.svg
new file mode 100644
index 0000000000..6fefd5569e
--- /dev/null
+++ b/etc/images/ui/checkbox-checked.svg
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+  <g>
+    <path d="M3.5 1A2.506 2.506 0 001 3.5v9C1 13.876 2.124 15 3.5 15h9c1.376 0 2.5-1.124 2.5-2.5v-9C15 2.124 13.876 1 12.5 1zm0 1h9c.84 0 1.5.66 1.5 1.5v9c0 .84-.66 1.5-1.5 1.5h-9c-.84 0-1.5-.66-1.5-1.5v-9C2 2.66 2.66 2 3.5 2z" overflow="visible" />
+    <path d="M14.5 3l-.5-.5L7.5 9 5 6.5l-2 2L7.5 13l7-7z" overflow="visible" />
+  </g>
+</svg>
diff --git a/etc/images/ui/checkbox-mixed.svg b/etc/images/ui/checkbox-mixed.svg
new file mode 100644
index 0000000000..13bccaa7ce
--- /dev/null
+++ b/etc/images/ui/checkbox-mixed.svg
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+  <g>
+    <path d="M3.5 1A2.506 2.506 0 001 3.5v9C1 13.876 2.124 15 3.5 15h9c1.376 0 2.5-1.124 2.5-2.5v-9C15 2.124 13.876 1 12.5 1zm0 1h9c.84 0 1.5.66 1.5 1.5v9c0 .84-.66 1.5-1.5 1.5h-9c-.84 0-1.5-.66-1.5-1.5v-9C2 2.66 2.66 2 3.5 2z" overflow="visible" />
+    <path d="M5 6a2 2 0 100 4h6a2 2 0 100-4z" overflow="visible" />
+  </g>
+</svg>
diff --git a/etc/images/ui/checkbox.svg b/etc/images/ui/checkbox.svg
new file mode 100644
index 0000000000..18cd25b43f
--- /dev/null
+++ b/etc/images/ui/checkbox.svg
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+  <path d="M3.5 1A2.506 2.506 0 001 3.5v9C1 13.876 2.124 15 3.5 15h9c1.376 0 2.5-1.124 2.5-2.5v-9C15 2.124 13.876 1 12.5 1zm0 1h9c.84 0 1.5.66 1.5 1.5v9c0 .84-.66 1.5-1.5 1.5h-9c-.84 0-1.5-.66-1.5-1.5v-9C2 2.66 2.66 2 3.5 2z" overflow="visible" />
+</svg>
diff --git a/etc/images/ui/radio-checked.svg b/etc/images/ui/radio-checked.svg
new file mode 100644
index 0000000000..db711841cf
--- /dev/null
+++ b/etc/images/ui/radio-checked.svg
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+  <g>
+    <path d="M8 5a3.001 3.001 0 000 6 3.001 3.001 0 000-6z" overflow="visible"/>
+    <path d="M8.004 1C4.144 1 1 4.144 1 8.004c0 3.86 3.144 7.006 7.004 7.006 3.86 0 7.006-3.146 7.006-7.006C15.01 4.144 11.864 1 8.004 1zm0 1a6.002 6.002 0 016.006 6.004 6.004 6.004 0 01-6.006 6.006A6.002 6.002 0 012 8.004 6 6 0 018.004 2z" overflow="visible"/>
+  </g>
+</svg>
diff --git a/etc/images/ui/radio-mixed.svg b/etc/images/ui/radio-mixed.svg
new file mode 100644
index 0000000000..5a8be0cf65
--- /dev/null
+++ b/etc/images/ui/radio-mixed.svg
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+  <g font-weight="400" fill="#474747">
+    <path d="M8 1C4.142 1 1 4.142 1 8s3.142 7 7 7 7-3.142 7-7-3.142-7-7-7zm0 1c3.316 0 6 2.684 6 6s-2.684 6-6 6-6-2.684-6-6 2.684-6 6-6z" overflow="visible" />
+    <path d="M5 6a2 2 0 100 4h6a2 2 0 100-4z" overflow="visible" />
+  </g>
+</svg>
diff --git a/etc/images/ui/radio.svg b/etc/images/ui/radio.svg
new file mode 100644
index 0000000000..0d649c99cd
--- /dev/null
+++ b/etc/images/ui/radio.svg
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+  <path d="M8 1C4.142 1 1 4.142 1 8s3.142 7 7 7 7-3.142 7-7-3.142-7-7-7zm0 1c3.316 0 6 2.684 6 6s-2.684 6-6 6-6-2.684-6-6 2.684-6 6-6z" overflow="visible" />
+</svg>
diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
index de2b5d4a7c..b8d1fad49c 100644
--- a/lisp/wid-edit.el
+++ b/lisp/wid-edit.el
@@ -745,7 +745,7 @@ widget-image-enable
   :type 'boolean)
 
 (defcustom widget-image-conversion
-  '((xpm ".xpm") (gif ".gif") (png ".png") (jpeg ".jpg" ".jpeg")
+  '((svg ".svg") (xpm ".xpm") (gif ".gif") (png ".png") (jpeg ".jpg" ".jpeg")
     (xbm ".xbm"))
   "Conversion alist from image formats to file name suffixes."
   :group 'widgets
@@ -2385,9 +2385,9 @@ 'checkbox
   ;; We could probably do the same job as the images using single
   ;; space characters in a boxed face with a stretch specification to
   ;; make them square.
-  :on-glyph "checked"
+  :on-glyph "ui/checkbox-checked"
   :off "[ ]"
-  :off-glyph "unchecked"
+  :off-glyph "ui/checkbox"
   :help-echo "Toggle this item."
   :action 'widget-checkbox-action)
 
@@ -2570,9 +2570,9 @@ 'radio-button
   :button-suffix ""
   :button-prefix ""
   :on "(*)"
-  :on-glyph "radio1"
+  :on-glyph "ui/radio-checked"
   :off "( )"
-  :off-glyph "radio0")
+  :off-glyph "ui/radio")
 
 (defun widget-radio-button-notify (widget _child &optional event)
   ;; Tell daddy.
-- 
2.30.1

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 12 Mar 2021 20:44:55 -0600
> Cc: 47074@debbugs.gnu.org
> 
> @@ -2385,9 +2385,9 @@ 'checkbox
>    ;; We could probably do the same job as the images using single
>    ;; space characters in a boxed face with a stretch specification to
>    ;; make them square.
> -  :on-glyph "checked"
> +  :on-glyph "ui/checkbox-checked"
>    :off "[ ]"
> -  :off-glyph "unchecked"
> +  :off-glyph "ui/checkbox"
>    :help-echo "Toggle this item."
>    :action 'widget-checkbox-action)

How will this work in an Emacs session that doesn't support SVG?  The
images/ui/ directory has only SVG images.  Am I missing something?

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> @@ -2385,9 +2385,9 @@ 'checkbox
>>    ;; We could probably do the same job as the images using single
>>    ;; space characters in a boxed face with a stretch specification to
>>    ;; make them square.
>> -  :on-glyph "checked"
>> +  :on-glyph "ui/checkbox-checked"
>>    :off "[ ]"
>> -  :off-glyph "unchecked"
>> +  :off-glyph "ui/checkbox"
>>    :help-echo "Toggle this item."
>>    :action 'widget-checkbox-action)
>
> How will this work in an Emacs session that doesn't support SVG?  The
> images/ui/ directory has only SVG images.  Am I missing something?

There are only SVG images in that directory, yes.

IIUC, it would show the :on and :off text on such configurations,
i.e. "[X]" and "[ ]".

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 13 Mar 2021 01:47:25 -0600
> Cc: alan@idiocy.org, 47074@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> @@ -2385,9 +2385,9 @@ 'checkbox
> >>    ;; We could probably do the same job as the images using single
> >>    ;; space characters in a boxed face with a stretch specification to
> >>    ;; make them square.
> >> -  :on-glyph "checked"
> >> +  :on-glyph "ui/checkbox-checked"
> >>    :off "[ ]"
> >> -  :off-glyph "unchecked"
> >> +  :off-glyph "ui/checkbox"
> >>    :help-echo "Toggle this item."
> >>    :action 'widget-checkbox-action)
> >
> > How will this work in an Emacs session that doesn't support SVG?  The
> > images/ui/ directory has only SVG images.  Am I missing something?
> 
> There are only SVG images in that directory, yes.
> 
> IIUC, it would show the :on and :off text on such configurations,
> i.e. "[X]" and "[ ]".

That'd be a regression, no?  Can we arrange for the old XPM files to
be used if SVG is not available?

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> IIUC, it would show the :on and :off text on such configurations,
>> i.e. "[X]" and "[ ]".
>
> That'd be a regression, no?

Are there any systems we care about where librsvg is not available?  Do
we think it is important to support these graphical icons on those
systems?  If the answer is yes to both of these questions, then I guess
we should count it as a regression.

(A priori, I think it sounds okay to expect users to build with librsvg
if they want to have graphical icons.  Presumably/hopefully all
distributions are already doing it.)

> Can we arrange for the old XPM files to be used if SVG is not
> available?

Perhaps fixing this it is as easy as moving/copying the old XPM files to
ui/<newnames>.xpm, but I'd need to test it as I didn't study the code
very closely.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 13 Mar 2021 04:35:43 -0600
> Cc: alan@idiocy.org, 47074@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> IIUC, it would show the :on and :off text on such configurations,
> >> i.e. "[X]" and "[ ]".
> >
> > That'd be a regression, no?
> 
> Are there any systems we care about where librsvg is not available?  Do
> we think it is important to support these graphical icons on those
> systems?  If the answer is yes to both of these questions, then I guess
> we should count it as a regression.

Since librsvg is an _optional_ dependency, IMO the answer is YES by
definition, right?

> > Can we arrange for the old XPM files to be used if SVG is not
> > available?
> 
> Perhaps fixing this it is as easy as moving/copying the old XPM files to
> ui/<newnames>.xpm, but I'd need to test it as I didn't study the code
> very closely.

Yes, I think copying the XPM file would be okay.

Alternatively, we could move and rename the new SVG files.  They are
in a separate directory just because of the license?  If so, I don't
think that's a string enough reason to segregate them, we could just
mention in the README in etc/images that these files (with an explicit
list) are from so-and-so place under such-and-such license.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Since librsvg is an _optional_ dependency, IMO the answer is YES by
> definition, right?

OK.

>> Perhaps fixing this it is as easy as moving/copying the old XPM files to
>> ui/<newnames>.xpm, but I'd need to test it as I didn't study the code
>> very closely.
>
> Yes, I think copying the XPM file would be okay.
>
> Alternatively, we could move and rename the new SVG files.  They are
> in a separate directory just because of the license?  If so, I don't
> think that's a string enough reason to segregate them, we could just
> mention in the README in etc/images that these files (with an explicit
> list) are from so-and-so place under such-and-such license.

I mostly placed them there as the old names were to my mind not ideal,
and I hoped we could have something better/more consistent.

Here's a comparison:

    OLD NAME          NEW NAME
    ---------------   ---------------
    checked.xpm       ui/checkbox.svg
    unchecked.xpm     ui/checkbox-checked.svg
    N/A               ui/checkbox-mixed.svg
    N/A               ui/radio-checked.svg
    N/A               ui/radio-mixed.svg
    N/A               ui/radio.svg
    custom/down.xpm   ui/triangle-down.svg   [not yet added]
    N/A               ui/triangle-left.svg   [not yet added]
    custom/right.xpm  ui/triangle-right.svg  [not yet added]
    N/A               ui/triangle-up.svg     [not yet added]

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 13 Mar 2021 05:51:26 -0600
> Cc: alan@idiocy.org, 47074@debbugs.gnu.org
> 
> I mostly placed them there as the old names were to my mind not ideal,
> and I hoped we could have something better/more consistent.
> 
> Here's a comparison:
> 
>     OLD NAME          NEW NAME
>     ---------------   ---------------
>     checked.xpm       ui/checkbox.svg
>     unchecked.xpm     ui/checkbox-checked.svg
>     N/A               ui/checkbox-mixed.svg
>     N/A               ui/radio-checked.svg
>     N/A               ui/radio-mixed.svg
>     N/A               ui/radio.svg
>     custom/down.xpm   ui/triangle-down.svg   [not yet added]
>     N/A               ui/triangle-left.svg   [not yet added]
>     custom/right.xpm  ui/triangle-right.svg  [not yet added]
>     N/A               ui/triangle-up.svg     [not yet added]

I don't think names matter in this case, as no one sees them except
the source code.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think names matter in this case, as no one sees them except
> the source code.

If we only consider custom.el I agree completely.  But I was personally
hoping that these "improved" icons will see some use also outside of
custom, including perhaps in third-party packages.  It would be nice to
have these better names for such use.

Would it be okay to just have two names/locations for these XPM files?

(I seem to remember that we can't use symlinks due to our support for
Windows or something?  But perhaps even without symlinking the cost of
duplicating the XPM files is fairly low, as they are only around 1 KiB
each.  The biggest problem would be if someone decides to change these
files (but I see no changes in the last decade, and presumably XPM will
only get less relevant over time).)

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 13 Mar 2021 10:44:46 -0600
> Cc: alan@idiocy.org, 47074@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't think names matter in this case, as no one sees them except
> > the source code.
> 
> If we only consider custom.el I agree completely.  But I was personally
> hoping that these "improved" icons will see some use also outside of
> custom, including perhaps in third-party packages.  It would be nice to
> have these better names for such use.

Are they really significantly better?  I fail to see that.

> Would it be okay to just have two names/locations for these XPM files?

Do we have to?

> (I seem to remember that we can't use symlinks due to our support for
> Windows or something?

Symlinks in tarballs are trouble, not only on Windows.

I feel we are again bikeshedding here, sorry.  It's an insignificant
issue from where I stand.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Alan Third]

On Fri, Mar 12, 2021 at 08:44:55PM -0600, Stefan Kangas wrote:
> Alan Third <alan@idiocy.org> writes:
> How would a patch like the attached relate to the changes you propose,
> Alan?

Yes. With a few small changed to the SVG files, and then the ability
to create the CSS file for librsvg, we will be able to make these
icons appear at exactly the same size as the text. Or, if we wanted, a
consistent relation to the text.

I'll have a look and see what I think is the best approach to
generating the CSS.
-- 
Alan Third

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Alan Third]

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

On Fri, Mar 12, 2021 at 08:44:55PM -0600, Stefan Kangas wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > On Thu, Mar 11, 2021 at 10:01:11PM +0200, Eli Zaretskii wrote:
> >> >
> >> > I think SVG is obviously much preferable to XPM, but there is still the
> >> > problem that the images don't scale with the text.  Do we have a general
> >> > solution to that?  If not, should we have one?
> >>
> >> With SVG, I believe we could.  (We can scale other kinds of images as
> >> well, but they don't look well when enlarged, AFAIK.)
> >
> > I've been thinking about this, and assuming we can extract the font
> > name and size from the face in C then we can create a default CSS
> > stylesheet that should make 1em in an SVG equivalent to the actual
> > Emacs font height.
> 
> I took a stab at adding SVG icons, as found in the GNOME Adwaita Icon
> Theme.  I had to scrub some color details from the SVG files by hand,
> but they now seem to automagically adapt to the :foreground and
> :background of the current face (but I could be wrong about that as I
> don't understand how this is supposed to work).
> 
> How would a patch like the attached relate to the changes you propose,
> Alan?

I've attached a proof of concept patch for what I'm talking about.
Stefan's patch must be applied first and it requires at least librsvg
2.48 and might foul up if create-image starts automatically changing
scale (it's fine here).

Does this look like the sort of behaviour you were thinking of, in
terms of icon sizing?
-- 
Alan Third

[-- Attachment #2: 0001-Autoresizing-SVG-files-PoC.patch --]
[-- Type: text/plain, Size: 10311 bytes --]

From 27e284644ae30f767d04847fc45accb4f18f33ab Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Sun, 14 Mar 2021 13:41:25 +0000
Subject: [PATCH] Autoresizing SVG files PoC

Requires librsvg 2.48.
---
 etc/images/ui/checkbox-checked.svg |  2 +-
 etc/images/ui/checkbox-mixed.svg   |  2 +-
 etc/images/ui/checkbox.svg         |  2 +-
 etc/images/ui/radio-checked.svg    |  2 +-
 etc/images/ui/radio-mixed.svg      |  2 +-
 etc/images/ui/radio.svg            |  2 +-
 src/dispextern.h                   |  4 ++++
 src/image.c                        | 25 +++++++++++++++++++------
 8 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/etc/images/ui/checkbox-checked.svg b/etc/images/ui/checkbox-checked.svg
index 6fefd5569e..559c24af72 100644
--- a/etc/images/ui/checkbox-checked.svg
+++ b/etc/images/ui/checkbox-checked.svg
@@ -1,4 +1,4 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+<svg xmlns="http://www.w3.org/2000/svg" preserveAspectRatio="xMidYMid meet" width="1em" height="1em" viewBox="0 0 16 16">
   <g>
     <path d="M3.5 1A2.506 2.506 0 001 3.5v9C1 13.876 2.124 15 3.5 15h9c1.376 0 2.5-1.124 2.5-2.5v-9C15 2.124 13.876 1 12.5 1zm0 1h9c.84 0 1.5.66 1.5 1.5v9c0 .84-.66 1.5-1.5 1.5h-9c-.84 0-1.5-.66-1.5-1.5v-9C2 2.66 2.66 2 3.5 2z" overflow="visible" />
     <path d="M14.5 3l-.5-.5L7.5 9 5 6.5l-2 2L7.5 13l7-7z" overflow="visible" />
diff --git a/etc/images/ui/checkbox-mixed.svg b/etc/images/ui/checkbox-mixed.svg
index 13bccaa7ce..4dc71c3764 100644
--- a/etc/images/ui/checkbox-mixed.svg
+++ b/etc/images/ui/checkbox-mixed.svg
@@ -1,4 +1,4 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+<svg xmlns="http://www.w3.org/2000/svg" width="1em" height="1em" viewBox="0 0 16 16">
   <g>
     <path d="M3.5 1A2.506 2.506 0 001 3.5v9C1 13.876 2.124 15 3.5 15h9c1.376 0 2.5-1.124 2.5-2.5v-9C15 2.124 13.876 1 12.5 1zm0 1h9c.84 0 1.5.66 1.5 1.5v9c0 .84-.66 1.5-1.5 1.5h-9c-.84 0-1.5-.66-1.5-1.5v-9C2 2.66 2.66 2 3.5 2z" overflow="visible" />
     <path d="M5 6a2 2 0 100 4h6a2 2 0 100-4z" overflow="visible" />
diff --git a/etc/images/ui/checkbox.svg b/etc/images/ui/checkbox.svg
index 18cd25b43f..28e350c46b 100644
--- a/etc/images/ui/checkbox.svg
+++ b/etc/images/ui/checkbox.svg
@@ -1,3 +1,3 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+<svg xmlns="http://www.w3.org/2000/svg" width="1em" height="1em" viewBox="0 0 16 16">
   <path d="M3.5 1A2.506 2.506 0 001 3.5v9C1 13.876 2.124 15 3.5 15h9c1.376 0 2.5-1.124 2.5-2.5v-9C15 2.124 13.876 1 12.5 1zm0 1h9c.84 0 1.5.66 1.5 1.5v9c0 .84-.66 1.5-1.5 1.5h-9c-.84 0-1.5-.66-1.5-1.5v-9C2 2.66 2.66 2 3.5 2z" overflow="visible" />
 </svg>
diff --git a/etc/images/ui/radio-checked.svg b/etc/images/ui/radio-checked.svg
index db711841cf..e7a22ccf3f 100644
--- a/etc/images/ui/radio-checked.svg
+++ b/etc/images/ui/radio-checked.svg
@@ -1,4 +1,4 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+<svg xmlns="http://www.w3.org/2000/svg" width="1em" height="1em" viewBox="0 0 16 16">
   <g>
     <path d="M8 5a3.001 3.001 0 000 6 3.001 3.001 0 000-6z" overflow="visible"/>
     <path d="M8.004 1C4.144 1 1 4.144 1 8.004c0 3.86 3.144 7.006 7.004 7.006 3.86 0 7.006-3.146 7.006-7.006C15.01 4.144 11.864 1 8.004 1zm0 1a6.002 6.002 0 016.006 6.004 6.004 6.004 0 01-6.006 6.006A6.002 6.002 0 012 8.004 6 6 0 018.004 2z" overflow="visible"/>
diff --git a/etc/images/ui/radio-mixed.svg b/etc/images/ui/radio-mixed.svg
index 5a8be0cf65..bdd76f85a0 100644
--- a/etc/images/ui/radio-mixed.svg
+++ b/etc/images/ui/radio-mixed.svg
@@ -1,4 +1,4 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+<svg xmlns="http://www.w3.org/2000/svg" width="1em" height="1em" viewBox="0 0 16 16">
   <g font-weight="400" fill="#474747">
     <path d="M8 1C4.142 1 1 4.142 1 8s3.142 7 7 7 7-3.142 7-7-3.142-7-7-7zm0 1c3.316 0 6 2.684 6 6s-2.684 6-6 6-6-2.684-6-6 2.684-6 6-6z" overflow="visible" />
     <path d="M5 6a2 2 0 100 4h6a2 2 0 100-4z" overflow="visible" />
diff --git a/etc/images/ui/radio.svg b/etc/images/ui/radio.svg
index 0d649c99cd..f076ad78d4 100644
--- a/etc/images/ui/radio.svg
+++ b/etc/images/ui/radio.svg
@@ -1,3 +1,3 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+<svg xmlns="http://www.w3.org/2000/svg" width="1em" height="1em" viewBox="0 0 16 16">
   <path d="M8 1C4.142 1 1 4.142 1 8s3.142 7 7 7 7-3.142 7-7-3.142-7-7-7zm0 1c3.316 0 6 2.684 6 6s-2.684 6-6 6-6-2.684-6-6 2.684-6 6-6z" overflow="visible" />
 </svg>
diff --git a/src/dispextern.h b/src/dispextern.h
index f4e872644d..3e801672ec 100644
--- a/src/dispextern.h
+++ b/src/dispextern.h
@@ -3066,6 +3066,10 @@ reset_mouse_highlight (Mouse_HLInfo *hlinfo)
      is created.  */
   unsigned long face_foreground, face_background;
 
+  /* Size of the font, only really relevant for types like SVG that
+     allow us to draw text. */
+  int face_font_size;
+
   /* True if this image has a `transparent' background -- that is, is
      uses an image mask.  The accessor macro for this is
      `IMAGE_BACKGROUND_TRANSPARENT'.  */
diff --git a/src/image.c b/src/image.c
index b85418c690..4810329537 100644
--- a/src/image.c
+++ b/src/image.c
@@ -1605,7 +1605,7 @@ make_image_cache (void)
 static struct image *
 search_image_cache (struct frame *f, Lisp_Object spec, EMACS_UINT hash,
                     unsigned long foreground, unsigned long background,
-                    bool ignore_colors)
+                    int font_size, bool ignore_colors)
 {
   struct image *img;
   struct image_cache *c = FRAME_IMAGE_CACHE (f);
@@ -1629,7 +1629,8 @@ search_image_cache (struct frame *f, Lisp_Object spec, EMACS_UINT hash,
     if (img->hash == hash
 	&& !NILP (Fequal (img->spec, spec))
 	&& (ignore_colors || (img->face_foreground == foreground
-                              && img->face_background == background)))
+                              && img->face_background == background
+			      && img->face_font_size == font_size)))
       break;
   return img;
 }
@@ -1647,7 +1648,7 @@ uncache_image (struct frame *f, Lisp_Object spec)
      can have multiple copies of an image with the same spec. We want
      to remove them all to ensure the user doesn't see an old version
      of the image when the face changes.  */
-  while ((img = search_image_cache (f, spec, hash, 0, 0, true)))
+  while ((img = search_image_cache (f, spec, hash, 0, 0, 0, true)))
     {
       free_image (f, img);
       /* As display glyphs may still be referring to the image ID, we
@@ -2419,6 +2420,7 @@ lookup_image (struct frame *f, Lisp_Object spec, int face_id)
   struct face *face = FACE_FROM_ID (f, face_id);
   unsigned long foreground = FACE_COLOR_TO_PIXEL (face->foreground, f);
   unsigned long background = FACE_COLOR_TO_PIXEL (face->background, f);
+  int font_size = face->font->height;
 
   /* F must be a window-system frame, and SPEC must be a valid image
      specification.  */
@@ -2427,7 +2429,7 @@ lookup_image (struct frame *f, Lisp_Object spec, int face_id)
 
   /* Look up SPEC in the hash table of the image cache.  */
   hash = sxhash (spec);
-  img = search_image_cache (f, spec, hash, foreground, background, false);
+  img = search_image_cache (f, spec, hash, foreground, background, font_size, false);
   if (img && img->load_failed_p)
     {
       free_image (f, img);
@@ -2442,6 +2444,7 @@ lookup_image (struct frame *f, Lisp_Object spec, int face_id)
       cache_image (f, img);
       img->face_foreground = foreground;
       img->face_background = background;
+      img->face_font_size = font_size;
       img->load_failed_p = ! img->type->load_img (f, img);
 
       /* If we can't load the image, and we don't have a width and
@@ -9912,6 +9915,12 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
   g_type_init ();
 #endif
 
+  /* Generate the CSS for the SVG image.  */
+  char *css_spec = "svg{font-size:%4dpx}";
+  char *css = malloc(strlen (css_spec + 1));
+  sprintf (css, css_spec, img->face_font_size);
+  fprintf (stderr, "%s\n\n", css);
+
   /* Parse the unmodified SVG data so we can get its initial size.  */
 
 #if LIBRSVG_CHECK_VERSION (2, 32, 0)
@@ -9929,6 +9938,7 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
   /* Check rsvg_handle too, to avoid librsvg 2.40.13 bug (Bug#36773#26).  */
   if (!rsvg_handle || err) goto rsvg_error;
 
+  rsvg_handle_set_stylesheet (rsvg_handle, css, strlen (css), NULL);
   rsvg_handle_set_dpi_x_y (rsvg_handle, FRAME_DISPLAY_INFO (f)->resx,
                            FRAME_DISPLAY_INFO (f)->resy);
 #else
@@ -10054,7 +10064,7 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
     const char *wrapper =
       "<svg xmlns:xlink=\"http://www.w3.org/1999/xlink\" "
       "xmlns:xi=\"http://www.w3.org/2001/XInclude\" "
-      "style=\"color: #%06X; fill: currentColor;\" "
+      "style=\"color: #%06X; fill: currentColor\" "
       "width=\"%d\" height=\"%d\" preserveAspectRatio=\"none\" "
       "viewBox=\"0 0 %f %f\">"
       "<rect width=\"100%%\" height=\"100%%\" fill=\"#%06X\"/>"
@@ -10080,7 +10090,8 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
 
     if (!wrapped_contents
         || buffer_size <= snprintf (wrapped_contents, buffer_size, wrapper,
-                                    foreground & 0xFFFFFF, width, height,
+                                    foreground & 0xFFFFFF,
+				    width, height,
                                     viewbox_width, viewbox_height,
                                     background & 0xFFFFFF,
                                     SSDATA (encoded_contents)))
@@ -10088,6 +10099,7 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
 
     wrapped_size = strlen (wrapped_contents);
   }
+  fprintf (stderr, "%s\n\n", wrapped_contents);
 
   /* Now we parse the wrapped version.  */
 
@@ -10105,6 +10117,7 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
   /* Check rsvg_handle too, to avoid librsvg 2.40.13 bug (Bug#36773#26).  */
   if (!rsvg_handle || err) goto rsvg_error;
 
+  rsvg_handle_set_stylesheet (rsvg_handle, css, strlen (css), NULL);
   rsvg_handle_set_dpi_x_y (rsvg_handle, FRAME_DISPLAY_INFO (f)->resx,
                            FRAME_DISPLAY_INFO (f)->resy);
 #else
-- 
2.29.2

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Stefan Kangas]

Alan Third <alan@idiocy.org> writes:

> I've attached a proof of concept patch for what I'm talking about.
> Stefan's patch must be applied first and it requires at least librsvg
> 2.48 and might foul up if create-image starts automatically changing
> scale (it's fine here).
>
> Does this look like the sort of behaviour you were thinking of, in
> terms of icon sizing?

This is exactly the behavior I was thinking of, yes.  It looks and works
great in some minor testing.

Maybe Lars or Eli have additional comments, but LGTM.

Thank you.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sun, 14 Mar 2021 13:44:32 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, 47074@debbugs.gnu.org
> 
> This is exactly the behavior I was thinking of, yes.  It looks and works
> great in some minor testing.
> 
> Maybe Lars or Eli have additional comments, but LGTM.

The only question I have is what will happen if librsvg is older than
2.48?

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Alan Third]

On Sun, Mar 14, 2021 at 08:49:30PM +0200, Eli Zaretskii wrote:
> > From: Stefan Kangas <stefan@marxist.se>
> > Date: Sun, 14 Mar 2021 13:44:32 -0500
> > Cc: Eli Zaretskii <eliz@gnu.org>, 47074@debbugs.gnu.org
> > 
> > This is exactly the behavior I was thinking of, yes.  It looks and works
> > great in some minor testing.
> > 
> > Maybe Lars or Eli have additional comments, but LGTM.
> 
> The only question I have is what will happen if librsvg is older than
> 2.48?

It will work exactly as it works at the moment. The font size will be
set to the librsvg default, which I think is 16 pixels, so the images
will default to 16 pixels high.

The problem is that librsvg only provided the ability to set a
stylesheet in 2.48, for earlier versions we'd have to wrap the SVG,
similar to what we do at the moment for resizing, but we'd have to
wrap twice with two different wrappers (once to get the original size,
and once to generate the resized image). I'm not actually sure whether
we can reliably get the size of a wrapped image. I'll have to try it I
suppose.

It looks like the stylesheet change was only merged in last year, I
was forgetting this was added so recently.
-- 
Alan Third

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> Date: Sun, 14 Mar 2021 19:37:33 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Stefan Kangas <stefan@marxist.se>, 47074@debbugs.gnu.org
> 
> > The only question I have is what will happen if librsvg is older than
> > 2.48?
> 
> It will work exactly as it works at the moment. The font size will be
> set to the librsvg default, which I think is 16 pixels, so the images
> will default to 16 pixels high.

Then that's fine, I think.  Thanks for doing this.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Alan Third]

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

On Sun, Mar 14, 2021 at 09:52:58PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 14 Mar 2021 19:37:33 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: Stefan Kangas <stefan@marxist.se>, 47074@debbugs.gnu.org
> > 
> > > The only question I have is what will happen if librsvg is older than
> > > 2.48?
> > 
> > It will work exactly as it works at the moment. The font size will be
> > set to the librsvg default, which I think is 16 pixels, so the images
> > will default to 16 pixels high.
> 
> Then that's fine, I think.  Thanks for doing this.

Here's my final patch, then. Again Stefan's patch is required first.

I'm somewhat tempted to add a :css image attribute for SVG files to
allow the user to over-ride the default css, but I can do that later.
-- 
Alan Third

[-- Attachment #2: 0001-Set-CSS-for-SVG-files.patch --]
[-- Type: text/plain, Size: 12954 bytes --]

From 50d2b5968f25ff0c1915db324669f56ff035416c Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Mon, 15 Mar 2021 21:30:43 +0000
Subject: [PATCH] Set CSS for SVG files

* etc/images/ui/checkbox-checked.svg:
* etc/images/ui/checkbox-mixed.svg:
* etc/images/ui/checkbox.svg:
* etc/images/ui/radio-checked.svg:
* etc/images/ui/radio-mixed.svg:
* etc/images/ui/radio.svg: Set height to match the font size.
* src/dispextern.h (struct image): Add font details required for the CSS.
* src/image.c (free_image): Free the font family string.
(search_image_cache):
(uncache_image): Make image caching understand the font details.
(lookup_image): Handle the font details when generating the image and
looking up the cache.
(svg_css_length_to_pixels): Handle 'em' when we know the font size.
(svg_load_image): Generate the CSS and apply it to the SVG.
---
 etc/images/ui/checkbox-checked.svg |  2 +-
 etc/images/ui/checkbox-mixed.svg   |  2 +-
 etc/images/ui/checkbox.svg         |  2 +-
 etc/images/ui/radio-checked.svg    |  2 +-
 etc/images/ui/radio-mixed.svg      |  2 +-
 etc/images/ui/radio.svg            |  2 +-
 src/dispextern.h                   |  5 +++
 src/image.c                        | 64 +++++++++++++++++++++++-------
 8 files changed, 60 insertions(+), 21 deletions(-)

diff --git a/etc/images/ui/checkbox-checked.svg b/etc/images/ui/checkbox-checked.svg
index 6fefd5569e..b84dde1c3a 100644
--- a/etc/images/ui/checkbox-checked.svg
+++ b/etc/images/ui/checkbox-checked.svg
@@ -1,4 +1,4 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+<svg xmlns="http://www.w3.org/2000/svg" height="1em" viewBox="0 0 16 16">
   <g>
     <path d="M3.5 1A2.506 2.506 0 001 3.5v9C1 13.876 2.124 15 3.5 15h9c1.376 0 2.5-1.124 2.5-2.5v-9C15 2.124 13.876 1 12.5 1zm0 1h9c.84 0 1.5.66 1.5 1.5v9c0 .84-.66 1.5-1.5 1.5h-9c-.84 0-1.5-.66-1.5-1.5v-9C2 2.66 2.66 2 3.5 2z" overflow="visible" />
     <path d="M14.5 3l-.5-.5L7.5 9 5 6.5l-2 2L7.5 13l7-7z" overflow="visible" />
diff --git a/etc/images/ui/checkbox-mixed.svg b/etc/images/ui/checkbox-mixed.svg
index 13bccaa7ce..647a0ccf9b 100644
--- a/etc/images/ui/checkbox-mixed.svg
+++ b/etc/images/ui/checkbox-mixed.svg
@@ -1,4 +1,4 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+<svg xmlns="http://www.w3.org/2000/svg" height="1em" viewBox="0 0 16 16">
   <g>
     <path d="M3.5 1A2.506 2.506 0 001 3.5v9C1 13.876 2.124 15 3.5 15h9c1.376 0 2.5-1.124 2.5-2.5v-9C15 2.124 13.876 1 12.5 1zm0 1h9c.84 0 1.5.66 1.5 1.5v9c0 .84-.66 1.5-1.5 1.5h-9c-.84 0-1.5-.66-1.5-1.5v-9C2 2.66 2.66 2 3.5 2z" overflow="visible" />
     <path d="M5 6a2 2 0 100 4h6a2 2 0 100-4z" overflow="visible" />
diff --git a/etc/images/ui/checkbox.svg b/etc/images/ui/checkbox.svg
index 18cd25b43f..7cc1516220 100644
--- a/etc/images/ui/checkbox.svg
+++ b/etc/images/ui/checkbox.svg
@@ -1,3 +1,3 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+<svg xmlns="http://www.w3.org/2000/svg" height="1em" viewBox="0 0 16 16">
   <path d="M3.5 1A2.506 2.506 0 001 3.5v9C1 13.876 2.124 15 3.5 15h9c1.376 0 2.5-1.124 2.5-2.5v-9C15 2.124 13.876 1 12.5 1zm0 1h9c.84 0 1.5.66 1.5 1.5v9c0 .84-.66 1.5-1.5 1.5h-9c-.84 0-1.5-.66-1.5-1.5v-9C2 2.66 2.66 2 3.5 2z" overflow="visible" />
 </svg>
diff --git a/etc/images/ui/radio-checked.svg b/etc/images/ui/radio-checked.svg
index db711841cf..5354324c34 100644
--- a/etc/images/ui/radio-checked.svg
+++ b/etc/images/ui/radio-checked.svg
@@ -1,4 +1,4 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+<svg xmlns="http://www.w3.org/2000/svg" height="1em" viewBox="0 0 16 16">
   <g>
     <path d="M8 5a3.001 3.001 0 000 6 3.001 3.001 0 000-6z" overflow="visible"/>
     <path d="M8.004 1C4.144 1 1 4.144 1 8.004c0 3.86 3.144 7.006 7.004 7.006 3.86 0 7.006-3.146 7.006-7.006C15.01 4.144 11.864 1 8.004 1zm0 1a6.002 6.002 0 016.006 6.004 6.004 6.004 0 01-6.006 6.006A6.002 6.002 0 012 8.004 6 6 0 018.004 2z" overflow="visible"/>
diff --git a/etc/images/ui/radio-mixed.svg b/etc/images/ui/radio-mixed.svg
index 5a8be0cf65..e2a6fcae57 100644
--- a/etc/images/ui/radio-mixed.svg
+++ b/etc/images/ui/radio-mixed.svg
@@ -1,4 +1,4 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+<svg xmlns="http://www.w3.org/2000/svg" height="1em" viewBox="0 0 16 16">
   <g font-weight="400" fill="#474747">
     <path d="M8 1C4.142 1 1 4.142 1 8s3.142 7 7 7 7-3.142 7-7-3.142-7-7-7zm0 1c3.316 0 6 2.684 6 6s-2.684 6-6 6-6-2.684-6-6 2.684-6 6-6z" overflow="visible" />
     <path d="M5 6a2 2 0 100 4h6a2 2 0 100-4z" overflow="visible" />
diff --git a/etc/images/ui/radio.svg b/etc/images/ui/radio.svg
index 0d649c99cd..2593a78610 100644
--- a/etc/images/ui/radio.svg
+++ b/etc/images/ui/radio.svg
@@ -1,3 +1,3 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
+<svg xmlns="http://www.w3.org/2000/svg" height="1em" viewBox="0 0 16 16">
   <path d="M8 1C4.142 1 1 4.142 1 8s3.142 7 7 7 7-3.142 7-7-3.142-7-7-7zm0 1c3.316 0 6 2.684 6 6s-2.684 6-6 6-6-2.684-6-6 2.684-6 6-6z" overflow="visible" />
 </svg>
diff --git a/src/dispextern.h b/src/dispextern.h
index f4e872644d..a2ebd04f23 100644
--- a/src/dispextern.h
+++ b/src/dispextern.h
@@ -3066,6 +3066,11 @@ reset_mouse_highlight (Mouse_HLInfo *hlinfo)
      is created.  */
   unsigned long face_foreground, face_background;
 
+  /* Details of the font, only really relevant for types like SVG that
+     allow us to draw text. */
+  int face_font_size;
+  char *face_font_family;
+
   /* True if this image has a `transparent' background -- that is, is
      uses an image mask.  The accessor macro for this is
      `IMAGE_BACKGROUND_TRANSPARENT'.  */
diff --git a/src/image.c b/src/image.c
index b85418c690..3d504effa6 100644
--- a/src/image.c
+++ b/src/image.c
@@ -1207,6 +1207,7 @@ free_image (struct frame *f, struct image *img)
 
       /* Free resources, then free IMG.  */
       img->type->free_img (f, img);
+      xfree (img->face_font_family);
       xfree (img);
     }
 }
@@ -1605,7 +1606,7 @@ make_image_cache (void)
 static struct image *
 search_image_cache (struct frame *f, Lisp_Object spec, EMACS_UINT hash,
                     unsigned long foreground, unsigned long background,
-                    bool ignore_colors)
+                    int font_size, char *font_family, bool ignore_colors)
 {
   struct image *img;
   struct image_cache *c = FRAME_IMAGE_CACHE (f);
@@ -1629,7 +1630,10 @@ search_image_cache (struct frame *f, Lisp_Object spec, EMACS_UINT hash,
     if (img->hash == hash
 	&& !NILP (Fequal (img->spec, spec))
 	&& (ignore_colors || (img->face_foreground == foreground
-                              && img->face_background == background)))
+                              && img->face_background == background
+			      && img->face_font_size == font_size
+			      && (font_family
+				  &&!strcmp (font_family, img->face_font_family)))))
       break;
   return img;
 }
@@ -1647,7 +1651,7 @@ uncache_image (struct frame *f, Lisp_Object spec)
      can have multiple copies of an image with the same spec. We want
      to remove them all to ensure the user doesn't see an old version
      of the image when the face changes.  */
-  while ((img = search_image_cache (f, spec, hash, 0, 0, true)))
+  while ((img = search_image_cache (f, spec, hash, 0, 0, 0, NULL, true)))
     {
       free_image (f, img);
       /* As display glyphs may still be referring to the image ID, we
@@ -2419,6 +2423,8 @@ lookup_image (struct frame *f, Lisp_Object spec, int face_id)
   struct face *face = FACE_FROM_ID (f, face_id);
   unsigned long foreground = FACE_COLOR_TO_PIXEL (face->foreground, f);
   unsigned long background = FACE_COLOR_TO_PIXEL (face->background, f);
+  int font_size = face->font->pixel_size;
+  char *font_family = SSDATA (face->lface[LFACE_FAMILY_INDEX]);
 
   /* F must be a window-system frame, and SPEC must be a valid image
      specification.  */
@@ -2427,7 +2433,8 @@ lookup_image (struct frame *f, Lisp_Object spec, int face_id)
 
   /* Look up SPEC in the hash table of the image cache.  */
   hash = sxhash (spec);
-  img = search_image_cache (f, spec, hash, foreground, background, false);
+  img = search_image_cache (f, spec, hash, foreground, background,
+			    font_size, font_family, false);
   if (img && img->load_failed_p)
     {
       free_image (f, img);
@@ -2442,6 +2449,9 @@ lookup_image (struct frame *f, Lisp_Object spec, int face_id)
       cache_image (f, img);
       img->face_foreground = foreground;
       img->face_background = background;
+      img->face_font_size = font_size;
+      img->face_font_family = malloc (strlen (font_family) + 1);
+      strcpy (img->face_font_family, font_family);
       img->load_failed_p = ! img->type->load_img (f, img);
 
       /* If we can't load the image, and we don't have a width and
@@ -9846,7 +9856,7 @@ svg_load (struct frame *f, struct image *img)
 
 #if LIBRSVG_CHECK_VERSION (2, 46, 0)
 static double
-svg_css_length_to_pixels (RsvgLength length, double dpi)
+svg_css_length_to_pixels (RsvgLength length, double dpi, int font_size)
 {
   double value = length.length;
 
@@ -9874,9 +9884,16 @@ svg_css_length_to_pixels (RsvgLength length, double dpi)
     case RSVG_UNIT_IN:
       value *= dpi;
       break;
+#if LIBRSVG_CHECK_VERSION (2, 48, 0)
+      /* We don't know exactly what font size is used on older librsvg
+	 versions.  */
+    case RSVG_UNIT_EM:
+      value *= font_size;
+      break;
+#endif
     default:
-      /* Probably one of em, ex, or %.  We can't know what the pixel
-         value is without more information.  */
+      /* Probably ex or %.  We can't know what the pixel value is
+         without more information.  */
       value = 0;
     }
 
@@ -9931,6 +9948,16 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
 
   rsvg_handle_set_dpi_x_y (rsvg_handle, FRAME_DISPLAY_INFO (f)->resx,
                            FRAME_DISPLAY_INFO (f)->resy);
+
+#if LIBRSVG_CHECK_VERSION (2, 48, 0)
+  /* Generate the CSS for the SVG image.  */
+  char *css_spec = "svg{font-family:\"%s\";font-size:%4dpx}";
+  int css_len = strlen (css_spec) + strlen (img->face_font_family);
+  char *css = xmalloc(css_len);
+  snprintf (css, css_len, css_spec, img->face_font_family, img->face_font_size);
+  rsvg_handle_set_stylesheet (rsvg_handle, css, strlen (css), NULL);
+#endif
+
 #else
   /* Make a handle to a new rsvg object.  */
   rsvg_handle = rsvg_handle_new ();
@@ -9973,20 +10000,20 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
   if (has_width && has_height)
     {
       /* Success!  We can use these values directly.  */
-      viewbox_width = svg_css_length_to_pixels (iwidth, dpi);
-      viewbox_height = svg_css_length_to_pixels (iheight, dpi);
+      viewbox_width = svg_css_length_to_pixels (iwidth, dpi, img->face_font_size);
+      viewbox_height = svg_css_length_to_pixels (iheight, dpi, img->face_font_size);
     }
   else if (has_width && has_viewbox)
     {
-      viewbox_width = svg_css_length_to_pixels (iwidth, dpi);
-      viewbox_height = svg_css_length_to_pixels (iwidth, dpi)
-        * viewbox.width / viewbox.height;
+      viewbox_width = svg_css_length_to_pixels (iwidth, dpi, img->face_font_size);
+      viewbox_height = svg_css_length_to_pixels (iwidth, dpi, img->face_font_size)
+        * viewbox.height / viewbox.width;
     }
   else if (has_height && has_viewbox)
     {
-      viewbox_height = svg_css_length_to_pixels (iheight, dpi);
-      viewbox_width = svg_css_length_to_pixels (iheight, dpi)
-        * viewbox.height / viewbox.width;
+      viewbox_height = svg_css_length_to_pixels (iheight, dpi, img->face_font_size);
+      viewbox_width = svg_css_length_to_pixels (iheight, dpi, img->face_font_size)
+        * viewbox.width / viewbox.height;
     }
   else if (has_viewbox)
     {
@@ -10107,6 +10134,10 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
 
   rsvg_handle_set_dpi_x_y (rsvg_handle, FRAME_DISPLAY_INFO (f)->resx,
                            FRAME_DISPLAY_INFO (f)->resy);
+
+#if LIBRSVG_CHECK_VERSION (2, 48, 0)
+  rsvg_handle_set_stylesheet (rsvg_handle, css, strlen (css), NULL);
+#endif
 #else
   /* Make a handle to a new rsvg object.  */
   rsvg_handle = rsvg_handle_new ();
@@ -10139,6 +10170,7 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
   if (!pixbuf) goto rsvg_error;
   g_object_unref (rsvg_handle);
   xfree (wrapped_contents);
+  xfree (css);
 
   /* Extract some meta data from the svg handle.  */
   width     = gdk_pixbuf_get_width (pixbuf);
@@ -10210,6 +10242,8 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
     g_object_unref (rsvg_handle);
   if (wrapped_contents)
     xfree (wrapped_contents);
+  if (css)
+    xfree (css);
   /* FIXME: Use error->message so the user knows what is the actual
      problem with the image.  */
   image_error ("Error parsing SVG image `%s'", img->spec);
-- 
2.29.2

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> Date: Mon, 15 Mar 2021 21:34:24 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: stefan@marxist.se, 47074@debbugs.gnu.org
> 
> Here's my final patch, then. Again Stefan's patch is required first.

Thanks.  As discussed elsewhere, Stefan's patch will have to be
slightly reworked to allow Emacs without SVG support to display
equivalent images of other formats.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 15 Mar 2021 21:34:24 +0000
>> From: Alan Third <alan@idiocy.org>
>> Cc: stefan@marxist.se, 47074@debbugs.gnu.org
>>
>> Here's my final patch, then. Again Stefan's patch is required first.
>
> Thanks.  As discussed elsewhere, Stefan's patch will have to be
> slightly reworked to allow Emacs without SVG support to display
> equivalent images of other formats.

I have now pushed it to master.  The XPM files are now used when
configuring --without-rsvg, and SVG is used otherwise (the default
case).

Eli insisted on keeping the old file names, so the file names in your
patch will need to be changed accordingly.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Alan Third]

On Sat, Apr 03, 2021 at 03:06:57PM -0500, Stefan Kangas wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Mon, 15 Mar 2021 21:34:24 +0000
> >> From: Alan Third <alan@idiocy.org>
> >> Cc: stefan@marxist.se, 47074@debbugs.gnu.org
> >>
> >> Here's my final patch, then. Again Stefan's patch is required first.
> >
> > Thanks.  As discussed elsewhere, Stefan's patch will have to be
> > slightly reworked to allow Emacs without SVG support to display
> > equivalent images of other formats.
> 
> I have now pushed it to master.  The XPM files are now used when
> configuring --without-rsvg, and SVG is used otherwise (the default
> case).
> 
> Eli insisted on keeping the old file names, so the file names in your
> patch will need to be changed accordingly.

I've pushed a change up, so hopefully it should all Just Work now.

Thanks!
-- 
Alan Third

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Stefan Kangas]

Alan Third <alan@idiocy.org> writes:

> I've pushed a change up, so hopefully it should all Just Work now.

It works perfectly, thank you!

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> Date: Sat, 3 Apr 2021 23:28:35 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, 47074-done@debbugs.gnu.org
> 
> I've pushed a change up, so hopefully it should all Just Work now.

Alan, this patch calls malloc to allocate face_font_family, but then
calls xfree to free it.  Why didn't you call xmalloc to allocate?
that's currently the only caller of malloc in the entire image.c.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Alan Third]

On Sun, Apr 04, 2021 at 02:37:12PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 3 Apr 2021 23:28:35 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, 47074-done@debbugs.gnu.org
> > 
> > I've pushed a change up, so hopefully it should all Just Work now.
> 
> Alan, this patch calls malloc to allocate face_font_family, but then
> calls xfree to free it.  Why didn't you call xmalloc to allocate?
> that's currently the only caller of malloc in the entire image.c.

I originally used malloc, then realised every other call is to xmalloc
and thought I'd fixed them all.

This change appears to have been particularly bad, apologies to
everyone for the mess I've caused.
-- 
Alan Third

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> Date: Sun, 4 Apr 2021 12:44:00 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: stefan@marxist.se, 47074@debbugs.gnu.org
> 
> > Alan, this patch calls malloc to allocate face_font_family, but then
> > calls xfree to free it.  Why didn't you call xmalloc to allocate?
> > that's currently the only caller of malloc in the entire image.c.
> 
> I originally used malloc, then realised every other call is to xmalloc
> and thought I'd fixed them all.

OK, I fixed.

> This change appears to have been particularly bad, apologies to
> everyone for the mess I've caused.

No need to apologize, thanks for your work.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 3 Apr 2021 15:06:57 -0500
> Cc: Alan Third <alan@idiocy.org>, 47074@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Mon, 15 Mar 2021 21:34:24 +0000
> >> From: Alan Third <alan@idiocy.org>
> >> Cc: stefan@marxist.se, 47074@debbugs.gnu.org
> >>
> >> Here's my final patch, then. Again Stefan's patch is required first.
> >
> > Thanks.  As discussed elsewhere, Stefan's patch will have to be
> > slightly reworked to allow Emacs without SVG support to display
> > equivalent images of other formats.
> 
> I have now pushed it to master.  The XPM files are now used when
> configuring --without-rsvg, and SVG is used otherwise (the default
> case).

Thanks.  How can this new feature be tested?  That is, how can I be
sure my Emacs indeed loads the SVG images when they are available?

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> I have now pushed it to master.  The XPM files are now used when
>> configuring --without-rsvg, and SVG is used otherwise (the default
>> case).
>
> Thanks.  How can this new feature be tested?  That is, how can I be
> sure my Emacs indeed loads the SVG images when they are available?

I have tested it using `M-x customize-face RET menu RET' and then "Show
all attributes".

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

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

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sun, 4 Apr 2021 04:21:09 -0500
> Cc: alan@idiocy.org, 47074@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I have now pushed it to master.  The XPM files are now used when
> >> configuring --without-rsvg, and SVG is used otherwise (the default
> >> case).
> >
> > Thanks.  How can this new feature be tested?  That is, how can I be
> > sure my Emacs indeed loads the SVG images when they are available?
> 
> I have tested it using `M-x customize-face RET menu RET' and then "Show
> all attributes".

Thanks.  The results on my system are much worse than the XPM images,
see the two attached screenshots.


[-- Attachment #2: SVG-widgets.PNG --]
[-- Type: image/png, Size: 45969 bytes --]

[-- Attachment #3: XPM-widgets.PNG --]
[-- Type: image/png, Size: 44483 bytes --]

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Alan Third]

On Sun, Apr 04, 2021 at 02:13:22PM +0300, Eli Zaretskii wrote:
> > From: Stefan Kangas <stefan@marxist.se>
> > Date: Sun, 4 Apr 2021 04:21:09 -0500
> > Cc: alan@idiocy.org, 47074@debbugs.gnu.org
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > >> I have now pushed it to master.  The XPM files are now used when
> > >> configuring --without-rsvg, and SVG is used otherwise (the default
> > >> case).
> > >
> > > Thanks.  How can this new feature be tested?  That is, how can I be
> > > sure my Emacs indeed loads the SVG images when they are available?
> > 
> > I have tested it using `M-x customize-face RET menu RET' and then "Show
> > all attributes".
> 
> Thanks.  The results on my system are much worse than the XPM images,
> see the two attached screenshots.

Something is going wrong with the rendering of the SVGs. It looks as
though the background is offset, and the background and foreground
colours are backwards.

What version of librsvg do you have?
-- 
Alan Third

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> Date: Sun, 4 Apr 2021 12:37:58 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Stefan Kangas <stefan@marxist.se>, 47074@debbugs.gnu.org
> 
> > Thanks.  The results on my system are much worse than the XPM images,
> > see the two attached screenshots.
> 
> Something is going wrong with the rendering of the SVGs. It looks as
> though the background is offset, and the background and foreground
> colours are backwards.
> 
> What version of librsvg do you have?

2.40.1.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

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

> Date: Sun, 04 Apr 2021 14:48:29 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: alan@idiocy.org, stefan@marxist.se, 47074@debbugs.gnu.org
> 
> > Something is going wrong with the rendering of the SVGs. It looks as
> > though the background is offset, and the background and foreground
> > colours are backwards.
> > 
> > What version of librsvg do you have?
> 
> 2.40.1.

To maybe facilitate the investigation of this issue, I attach 3 more
images created from checked.svg, with scale of 2, 5, and 10.  Note the
significant change between 2 and 5:


[-- Attachment #2: SVG-widgets2.PNG --]
[-- Type: image/png, Size: 48792 bytes --]

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Alan Third]

On Sun, Apr 04, 2021 at 03:38:25PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 04 Apr 2021 14:48:29 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: alan@idiocy.org, stefan@marxist.se, 47074@debbugs.gnu.org
> > 
> > > Something is going wrong with the rendering of the SVGs. It looks as
> > > though the background is offset, and the background and foreground
> > > colours are backwards.
> > > 
> > > What version of librsvg do you have?
> > 
> > 2.40.1.
> 
> To maybe facilitate the investigation of this issue, I attach 3 more
> images created from checked.svg, with scale of 2, 5, and 10.  Note the
> significant change between 2 and 5:

Ah yes, that definitely looks like the problem mentioned in my other
email. Thanks.

-- 
Alan Third

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Alan Third]

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

On Sun, Apr 04, 2021 at 02:48:29PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 4 Apr 2021 12:37:58 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: Stefan Kangas <stefan@marxist.se>, 47074@debbugs.gnu.org
> > 
> > > Thanks.  The results on my system are much worse than the XPM images,
> > > see the two attached screenshots.
> > 
> > Something is going wrong with the rendering of the SVGs. It looks as
> > though the background is offset, and the background and foreground
> > colours are backwards.
> > 
> > What version of librsvg do you have?
> 
> 2.40.1.

I can see something similar, but not exactly the same, on one of my
build virtual machines running 2.40.5. That particular problem looks
like an rsvg bug, since rsvg-view-3 displays it the same way.

It appears to be this (and one other related problem):

    https://github.com/svg/svgo/issues/822

I've reformatted the svg files so they display correctly here, but can
you please check that the attached patch fixes the problem for you as
well?
-- 
Alan Third

[-- Attachment #2: 0001-Work-around-librsvg-bug-bug-47074.patch --]
[-- Type: text/plain, Size: 5007 bytes --]

From 756306531f394d4160f6506042984f4583351258 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Sun, 4 Apr 2021 14:08:48 +0100
Subject: [PATCH] Work around librsvg bug (bug#47074)

Librsvg <= 2.40 has restrictions on how certain numbers can be run
together in path elements which do not match the SVG spec.

* etc/images/checkbox-mixed.svg:
* etc/images/checked.svg:
* etc/images/radio-checked.svg:
* etc/images/unchecked.svg: Separate problem numbers.
* etc/images/radio-mixed.svg: Separate problem numbers and color and
font-weight data.
---
 etc/images/checkbox-mixed.svg | 4 ++--
 etc/images/checked.svg        | 2 +-
 etc/images/radio-checked.svg  | 4 ++--
 etc/images/radio-mixed.svg    | 4 ++--
 etc/images/unchecked.svg      | 2 +-
 5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/etc/images/checkbox-mixed.svg b/etc/images/checkbox-mixed.svg
index 647a0ccf9b..6e46b803c8 100644
--- a/etc/images/checkbox-mixed.svg
+++ b/etc/images/checkbox-mixed.svg
@@ -1,6 +1,6 @@
 <svg xmlns="http://www.w3.org/2000/svg" height="1em" viewBox="0 0 16 16">
   <g>
-    <path d="M3.5 1A2.506 2.506 0 001 3.5v9C1 13.876 2.124 15 3.5 15h9c1.376 0 2.5-1.124 2.5-2.5v-9C15 2.124 13.876 1 12.5 1zm0 1h9c.84 0 1.5.66 1.5 1.5v9c0 .84-.66 1.5-1.5 1.5h-9c-.84 0-1.5-.66-1.5-1.5v-9C2 2.66 2.66 2 3.5 2z" overflow="visible" />
-    <path d="M5 6a2 2 0 100 4h6a2 2 0 100-4z" overflow="visible" />
+    <path d="M3.5 1A2.506 2.506 0 0 0 1 3.5v9C1 13.876 2.124 15 3.5 15h9c1.376 0 2.5-1.124 2.5-2.5v-9C15 2.124 13.876 1 12.5 1zm0 1h9c.84 0 1.5 .66 1.5 1.5v9c0 .84-.66 1.5-1.5 1.5h-9c-.84 0-1.5-.66-1.5-1.5v-9C2 2.66 2.66 2 3.5 2z" overflow="visible" />
+    <path d="M5 6a2 2 0 1 0 0 4h6a2 2 0 1 0 0 -4z" overflow="visible" />
   </g>
 </svg>
diff --git a/etc/images/checked.svg b/etc/images/checked.svg
index b84dde1c3a..4cbdef04f2 100644
--- a/etc/images/checked.svg
+++ b/etc/images/checked.svg
@@ -1,6 +1,6 @@
 <svg xmlns="http://www.w3.org/2000/svg" height="1em" viewBox="0 0 16 16">
   <g>
-    <path d="M3.5 1A2.506 2.506 0 001 3.5v9C1 13.876 2.124 15 3.5 15h9c1.376 0 2.5-1.124 2.5-2.5v-9C15 2.124 13.876 1 12.5 1zm0 1h9c.84 0 1.5.66 1.5 1.5v9c0 .84-.66 1.5-1.5 1.5h-9c-.84 0-1.5-.66-1.5-1.5v-9C2 2.66 2.66 2 3.5 2z" overflow="visible" />
+    <path d="M3.5 1A2.506 2.506 0 0 0 1 3.5v9C1 13.876 2.124 15 3.5 15h9c1.376 0 2.5-1.124 2.5-2.5v-9C15 2.124 13.876 1 12.5 1zm0 1h9c.84 0 1.5 .66 1.5 1.5v9c0 .84-.66 1.5-1.5 1.5h-9c-.84 0-1.5-.66-1.5-1.5v-9C2 2.66 2.66 2 3.5 2z" overflow="visible" />
     <path d="M14.5 3l-.5-.5L7.5 9 5 6.5l-2 2L7.5 13l7-7z" overflow="visible" />
   </g>
 </svg>
diff --git a/etc/images/radio-checked.svg b/etc/images/radio-checked.svg
index 5354324c34..8950b447a0 100644
--- a/etc/images/radio-checked.svg
+++ b/etc/images/radio-checked.svg
@@ -1,6 +1,6 @@
 <svg xmlns="http://www.w3.org/2000/svg" height="1em" viewBox="0 0 16 16">
   <g>
-    <path d="M8 5a3.001 3.001 0 000 6 3.001 3.001 0 000-6z" overflow="visible"/>
-    <path d="M8.004 1C4.144 1 1 4.144 1 8.004c0 3.86 3.144 7.006 7.004 7.006 3.86 0 7.006-3.146 7.006-7.006C15.01 4.144 11.864 1 8.004 1zm0 1a6.002 6.002 0 016.006 6.004 6.004 6.004 0 01-6.006 6.006A6.002 6.002 0 012 8.004 6 6 0 018.004 2z" overflow="visible"/>
+    <path d="M8 5a3.001 3.001 0 0 0 0 6 3.001 3.001 0 0 0 0 -6z" overflow="visible"/>
+    <path d="M8.004 1C4.144 1 1 4.144 1 8.004c0 3.86 3.144 7.006 7.004 7.006 3.86 0 7.006-3.146 7.006-7.006C15.01 4.144 11.864 1 8.004 1zm0 1a6.002 6.002 0 0 1 6.006 6.004 6.004 6.004 0 0 1 -6.006 6.006A6.002 6.002 0 0 1 2 8.004 6 6 0 0 1 8.004 2z" overflow="visible"/>
   </g>
 </svg>
diff --git a/etc/images/radio-mixed.svg b/etc/images/radio-mixed.svg
index e2a6fcae57..1b3bfa78e9 100644
--- a/etc/images/radio-mixed.svg
+++ b/etc/images/radio-mixed.svg
@@ -1,6 +1,6 @@
 <svg xmlns="http://www.w3.org/2000/svg" height="1em" viewBox="0 0 16 16">
-  <g font-weight="400" fill="#474747">
+  <g>
     <path d="M8 1C4.142 1 1 4.142 1 8s3.142 7 7 7 7-3.142 7-7-3.142-7-7-7zm0 1c3.316 0 6 2.684 6 6s-2.684 6-6 6-6-2.684-6-6 2.684-6 6-6z" overflow="visible" />
-    <path d="M5 6a2 2 0 100 4h6a2 2 0 100-4z" overflow="visible" />
+    <path d="M5 6a2 2 0 1 0 0 4h6a2 2 0 1 0 0 -4z" overflow="visible" />
   </g>
 </svg>
diff --git a/etc/images/unchecked.svg b/etc/images/unchecked.svg
index 7cc1516220..09bab8de95 100644
--- a/etc/images/unchecked.svg
+++ b/etc/images/unchecked.svg
@@ -1,3 +1,3 @@
 <svg xmlns="http://www.w3.org/2000/svg" height="1em" viewBox="0 0 16 16">
-  <path d="M3.5 1A2.506 2.506 0 001 3.5v9C1 13.876 2.124 15 3.5 15h9c1.376 0 2.5-1.124 2.5-2.5v-9C15 2.124 13.876 1 12.5 1zm0 1h9c.84 0 1.5.66 1.5 1.5v9c0 .84-.66 1.5-1.5 1.5h-9c-.84 0-1.5-.66-1.5-1.5v-9C2 2.66 2.66 2 3.5 2z" overflow="visible" />
+  <path d="M3.5 1A2.506 2.506 0 0 0 1 3.5v9C1 13.876 2.124 15 3.5 15h9c1.376 0 2.5-1.124 2.5-2.5v-9C15 2.124 13.876 1 12.5 1zm0 1h9c.84 0 1.5 .66 1.5 1.5v9c0 .84-.66 1.5-1.5 1.5h-9c-.84 0-1.5-.66-1.5-1.5v-9C2 2.66 2.66 2 3.5 2z" overflow="visible" />
 </svg>
-- 
2.29.2

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> Date: Sun, 4 Apr 2021 14:14:48 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: stefan@marxist.se, 47074@debbugs.gnu.org
> 
> > 2.40.1.
> 
> I can see something similar, but not exactly the same, on one of my
> build virtual machines running 2.40.5. That particular problem looks
> like an rsvg bug, since rsvg-view-3 displays it the same way.
> 
> It appears to be this (and one other related problem):
> 
>     https://github.com/svg/svgo/issues/822
> 
> I've reformatted the svg files so they display correctly here, but can
> you please check that the attached patch fixes the problem for you as
> well?

Thanks, this indeed fixes the problem here.

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Alan Third]

On Sun, Apr 04, 2021 at 04:22:19PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 4 Apr 2021 14:14:48 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: stefan@marxist.se, 47074@debbugs.gnu.org
> > 
> > > 2.40.1.
> > 
> > I can see something similar, but not exactly the same, on one of my
> > build virtual machines running 2.40.5. That particular problem looks
> > like an rsvg bug, since rsvg-view-3 displays it the same way.
> > 
> > It appears to be this (and one other related problem):
> > 
> >     https://github.com/svg/svgo/issues/822
> > 
> > I've reformatted the svg files so they display correctly here, but can
> > you please check that the attached patch fixes the problem for you as
> > well?
> 
> Thanks, this indeed fixes the problem here.

Thanks. I've pushed it to master.

Hopefully that's the last problem we find here. :)
-- 
Alan Third

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Eli Zaretskii]

> Date: Sun, 4 Apr 2021 14:28:25 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: stefan@marxist.se, 47074@debbugs.gnu.org
> 
> > >     https://github.com/svg/svgo/issues/822
> > > 
> > > I've reformatted the svg files so they display correctly here, but can
> > > you please check that the attached patch fixes the problem for you as
> > > well?
> > 
> > Thanks, this indeed fixes the problem here.
> 
> Thanks. I've pushed it to master.

Thank you.

Btw, since the SVG icons look quite differently from the XPM ones,
should we perhaps have a user options for preferring one type over the
other when both are available?  What do people think?

In any case, this change should be called out in NEWS, I think, as the
visual difference is prominent.

> Hopefully that's the last problem we find here. :)

Famous last words ;-)

bug#47074: Replace XPM icons with Unicode codepoints in customize/widgets

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks.  The results on my system are much worse than the XPM images,
> see the two attached screenshots.

Yes, that looks really bad.

Does anyone have any idea why this would happen on MS-Windows?

One workaround that comes to mind would be to make this system
dependent, but it would be better if we could find a proper fix.