High-res Customize icons

High-res Customize icons

[Yuan Fu]

I want to add high-res icons for Customize so it look better on Mac. The problem is, I couldn’t find the code that inserts the icons. I tried grepping for “xpm”, “bpm” and the like in custom.el and under /lisp but didn’t find anything. Where should I look at?

Yuan

Re: High-res Customize icons

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Tue, 21 Apr 2020 15:47:18 -0400
> 
> I want to add high-res icons for Customize so it look better on Mac. The problem is, I couldn’t find the code that inserts the icons. I tried grepping for “xpm”, “bpm” and the like in custom.el and under /lisp but didn’t find anything. Where should I look at?

If you mean the icons on the tool bar, look in tool-bar.el, the
function tool-bar--image-expression.

Re: High-res Customize icons

[Clément Pit-Claudel]

On 21/04/2020 22.23, Eli Zaretskii wrote:
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Tue, 21 Apr 2020 15:47:18 -0400
>>
>> I want to add high-res icons for Customize so it look better on Mac. The problem is, I couldn’t find the code that inserts the icons. I tried grepping for “xpm”, “bpm” and the like in custom.el and under /lisp but didn’t find anything. Where should I look at?
> 
> If you mean the icons on the tool bar, look in tool-bar.el, the
> function tool-bar--image-expression.

You might also be interested in q thread from 2017, https://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00470.html, where I posted a patch to make tool-bar--image-expression load PNG and SVG images.  I use a variant of that in my Emacs modes, to get scalable icons in (GTK) toolbars.

Re: High-res Customize icons

[chad]

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

Worth noting: If I understand correctly, the toolbar buttons are not the
same sort of emacs item as the Customize buttons; the former are restricted
specifically to the toolbar (and maybe the tab-bar, now?), and use a
traditional GUI update/repaint/etc method, whereas customize buttons appear
in buffers, and have to deal with the redisplay engine, as well as needing
to work in both terminal and various-gui frames.

It might be possible to use xwidgets to put gui toolkit buttons into
buffers. I've just started looking at the xwidget stuff myself, for webkit
integration. It seems somewhat unstable, but that might be webkit or my
unusual environment.

Hope that helps,
~Chad


On Tue, Apr 21, 2020 at 7:37 PM Clément Pit-Claudel <cpitclaudel@gmail.com>
wrote:

> On 21/04/2020 22.23, Eli Zaretskii wrote:
> >> From: Yuan Fu <casouri@gmail.com>
> >> Date: Tue, 21 Apr 2020 15:47:18 -0400
> >>
> >> I want to add high-res icons for Customize so it look better on Mac.
> The problem is, I couldn’t find the code that inserts the icons. I tried
> grepping for “xpm”, “bpm” and the like in custom.el and under /lisp but
> didn’t find anything. Where should I look at?
> >
> > If you mean the icons on the tool bar, look in tool-bar.el, the
> > function tool-bar--image-expression.
>
> You might also be interested in q thread from 2017,
> https://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00470.html,
> where I posted a patch to make tool-bar--image-expression load PNG and SVG
> images.  I use a variant of that in my Emacs modes, to get scalable icons
> in (GTK) toolbars.
>
>

[-- Attachment #2: Type: text/html, Size: 2190 bytes --]

Re: High-res Customize icons

[Yuan Fu]

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

Thanks, actually I was referring to the triangle icon in the customize buffer:



As for tool bar, normally I don’t enable it so it doesn’t bother me so much.

Yuan

[-- Attachment #2.1: Type: text/html, Size: 647 bytes --]

[-- Attachment #2.2: Screen Shot 2020-04-22 at 8.19.00 AM.png --]
[-- Type: image/png, Size: 25652 bytes --]

Re: High-res Customize icons

[Yuri Khan]

[-- Attachment #1.1: Type: text/plain, Size: 468 bytes --]

On Wed, 22 Apr 2020 at 19:24, Yuan Fu <casouri@gmail.com> wrote:

> Thanks, actually I was referring to the triangle icon in the customize
> buffer:
>
>
> You got it nice; it’s actually the right size, just jagged. For me on
GTK+/GNU/Linux, it’s rendered at half size.

I wonder if it’s even worthwhile having a bitmap for this. These days, it
could as well be any of ▶/▼, ▷/▽, ▸/▾, or ▹/▿. It would even work on some
text terminals.

[-- Attachment #1.2: Type: text/html, Size: 952 bytes --]

[-- Attachment #2: Screen Shot 2020-04-22 at 8.19.00 AM.png --]
[-- Type: image/png, Size: 25652 bytes --]

Re: High-res Customize icons

[Yuan Fu]

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



> On Apr 22, 2020, at 8:41 AM, Yuri Khan <yuri.v.khan@gmail.com> wrote:
> 
> On Wed, 22 Apr 2020 at 19:24, Yuan Fu <casouri@gmail.com <mailto:casouri@gmail.com>> wrote:
> Thanks, actually I was referring to the triangle icon in the customize buffer:
> 
> <Screen Shot 2020-04-22 at 8.19.00 AM.png>
> You got it nice; it’s actually the right size, just jagged. For me on GTK+/GNU/Linux, it’s rendered at half size.
> 
> I wonder if it’s even worthwhile having a bitmap for this. These days, it could as well be any of ▶/▼, ▷/▽, ▸/▾, or ▹/▿. It would even work on some text terminals.

That’s also a good idea. Different fonts could render the character slightly differently, but I guess that’s not a big problem. Anyway I still couldn’t find the code to modify to use other icons. The readme says those icons are made by Juri, maybe he knows.

Yuan

[-- Attachment #2: Type: text/html, Size: 1866 bytes --]

Re: High-res Customize icons

[Juri Linkov]

>         Thanks, actually I was referring to the triangle icon in the
>         customize buffer:
>
>         <Screen Shot 2020-04-22 at 8.19.00 AM.png>
>
>     You got it nice; it’s actually the right size, just jagged. For me on
>     GTK+/GNU/Linux, it’s rendered at half size.
>
>     I wonder if it’s even worthwhile having a bitmap for this. These days,
>     it could as well be any of ▶/▼, ▷/▽, ▸/▾, or ▹/▿. It would even work on
>     some text terminals.
>
> That’s also a good idea. Different fonts could render the character
> slightly differently, but I guess that’s not a big problem. Anyway I still
> couldn’t find the code to modify to use other icons. The readme says those
> icons are made by Juri, maybe he knows.

I see no alternative to current icons because ASCII art
characters have own problems explained by Eli in
https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00268.html

This is why the tab-bar moved from Unicode characters to images,
but another attempt to use SVG failed as was demonstrated in
https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00414.html

But in any case feel free to try other options.

BTW, if you want to see a funny effect, try typing 'r' when point
is on the arrow in the customize buffer - it will rotate the image :-)

There are other image keys used in the customize buffer,
e.g. '+' will zoom the image (function 'image-increase-size'),
so maybe you could just increase image size instead of using
2x image files.

Re: High-res Customize icons

[Yuan Fu]

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

> 
> I see no alternative to current icons because ASCII art
> characters have own problems explained by Eli in
> https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00268.html
> 
> This is why the tab-bar moved from Unicode characters to images,
> but another attempt to use SVG failed as was demonstrated in
> https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00414.html
> 
> But in any case feel free to try other options.
> 
> BTW, if you want to see a funny effect, try typing 'r' when point
> is on the arrow in the customize buffer - it will rotate the image :-)
> 
> There are other image keys used in the customize buffer,
> e.g. '+' will zoom the image (function 'image-increase-size'),
> so maybe you could just increase image size instead of using
> 2x image files.

Aha, that’s pretty cool :-) 

To be clear, I’m not looking for a larger icon, but one with higher resolution. “2x” basically means I make a 18x18 px image and render it in “9x9 size”, which looks better than a 9x9 image on a HiDPI screen. Maybe Apple can explain it better than I do: https://developer.apple.com/design/human-interface-guidelines/ios/icons-and-images/image-size-and-resolution/ <https://developer.apple.com/design/human-interface-guidelines/ios/icons-and-images/image-size-and-resolution/>. You can have a look at the images my previous message, the 9x9 one looks a bit fuzzy and the high-res one looks sharp.

Yuan

[-- Attachment #2: Type: text/html, Size: 2332 bytes --]

Re: High-res Customize icons

[Werner LEMBERG]

>>     I wonder if it’s even worthwhile having a bitmap for
>>     this. These days, it could as well be any of ▶/▼, ▷/▽, ▸/▾, or
>>     ▹/▿. It would even work on some text terminals.
> 
> I see no alternative to current icons because ASCII art characters
> have own problems explained by Eli in
> https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00268.html
> 
> This is why the tab-bar moved from Unicode characters to images, but
> another attempt to use SVG failed as was demonstrated in
> https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00414.html

Why not creating a specialized outline font family with the needed
glyphs?  Emacs could then always use it (and be distributed with these
fonts).

It should be straightforward to take a free font family, strip all
other glyphs, and modify the remaining symbols to make them fit.


    Werner

Re: High-res Customize icons

[Eli Zaretskii]

> Date: Thu, 23 Apr 2020 06:11:01 +0200 (CEST)
> From: Werner LEMBERG <wl@gnu.org>
> Cc: casouri@gmail.com, yuri.v.khan@gmail.com, cpitclaudel@gmail.com,
>  yandros@gmail.com, emacs-devel@gnu.org
> 
> Why not creating a specialized outline font family with the needed
> glyphs?  Emacs could then always use it (and be distributed with these
> fonts).
> 
> It should be straightforward to take a free font family, strip all
> other glyphs, and modify the remaining symbols to make them fit.

Unlike some other programs, Emacs doesn't use fonts directly, it does
so via system APIs that manage fonts.  Therefore, to use a font with
Emacs, you need to install it.  Installing a font means this
specialized font will be visible to all of the other applications, and
also to Emacs itself when it looks for a suitable font to display a
given character.

(I'm sure you, Werner, know all that, but I'd like to make sure
everyone else who reads this does.)

So installing an additional font (or a set of them, actually -- won't
we also need bold, italic, etc. variants?) affects the entire system
and affects Emacs itself, by adding a font that isn't really meant to
be used for displaying readable text in any script.  It's a trick that
we would use to work around the need to display an image.  I'm asking
whether this is such a good idea?  Won't this font get in the way?

What other applications are known to come with their own fonts and
install them into the global font space of the system?  Is this
considered a good practice?

Re: High-res Customize icons

[Clément Pit-Claudel]

On 23/04/2020 10.52, Eli Zaretskii wrote:
> What other applications are known to come with their own fonts and
> install them into the global font space of the system?  Is this
> considered a good practice?

It's a common practice for websites to come with their own fonts, but they are never installed in the global font space.  Some text editors ship with their own fonts (e.g. the JetBrains family of editors), but there, too, these fonts are not installed globally.

Re: High-res Customize icons

[Werner LEMBERG]

>> Why not creating a specialized outline font family with the needed
>> glyphs?  Emacs could then always use it (and be distributed with
>> these fonts).
>> 
>> It should be straightforward to take a free font family, strip all
>> other glyphs, and modify the remaining symbols to make them fit.
> 
> Unlike some other programs, Emacs doesn't use fonts directly, it does
> so via system APIs that manage fonts.

Yes.

> So installing an additional font (or a set of them, actually --
> won't we also need bold, italic, etc. variants?) affects the entire
> system and affects Emacs itself, by adding a font that isn't really
> meant to be used for displaying readable text in any script.  It's a
> trick that we would use to work around the need to display an image.
> I'm asking whether this is such a good idea?  Won't this font get in
> the way?

I think it is a good idea.  Today, OpenType fonts are standard on all
major platforms; it wouldn't be necessary to support any other, more
exotic or ancient font type.  Almost all of the needed symbols are
already available as Unicode characters, which means that such an
auxiliary font could be even used by other applications – another
advantage would be that Emacs in terminal mode could use *exactly* the
same character codes (without styling, of course) to display those
symbols.

To conform to the standard, glyphs that are not in Unicode would be
put into the PUA (Private User Area), again ensuring that there are no
conflicts with other applications.

> What other applications are known to come with their own fonts and
> install them into the global font space of the system?  Is this
> considered a good practice?

Well, on MacOS and GNU/Linux, it wouldn't be necessary to install the
font globally; instead, the Emacs binary can programmatically add a
local directory to the list of font directories scanned by
fontconfig.  I guess something similar is also available under Windows;
at least it should be doable under Windows 7 and newer, AFAICS:

  https://docs.microsoft.com/en-us/windows/win32/directwrite/custom-font-sets-win10

Looking around it seems even possible with GDI (then needing a
TrueType font):

  https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-addfontresourcea

However, this is just speculation on my side.

Supporting GDI, however, would have one limitation: No colored glyphs.


    Werner

Re: High-res Customize icons

[Eli Zaretskii]

> Date: Thu, 23 Apr 2020 19:49:51 +0200 (CEST)
> Cc: juri@linkov.net, casouri@gmail.com, yuri.v.khan@gmail.com,
>  cpitclaudel@gmail.com, yandros@gmail.com, emacs-devel@gnu.org
> From: Werner LEMBERG <wl@gnu.org>
> 
> > So installing an additional font (or a set of them, actually --
> > won't we also need bold, italic, etc. variants?) affects the entire
> > system and affects Emacs itself, by adding a font that isn't really
> > meant to be used for displaying readable text in any script.  It's a
> > trick that we would use to work around the need to display an image.
> > I'm asking whether this is such a good idea?  Won't this font get in
> > the way?
> 
> I think it is a good idea.  Today, OpenType fonts are standard on all
> major platforms;

That's not exactly why I asked whether it's a good idea.  I'm asking
whether it's a good idea to use characters as if they were small
images.  That is not what fonts were designed for, and that is
definitely not what font-selection code in Emacs was designed for.

> To conform to the standard, glyphs that are not in Unicode would be
> put into the PUA (Private User Area), again ensuring that there are no
> conflicts with other applications.

I'm very much against using PUA codepoints for this purpose (or any
purpose, really) in Emacs.  To say nothing of the fact that we
currently simply cannot.  That's a non-starter, from my POV.

> > What other applications are known to come with their own fonts and
> > install them into the global font space of the system?  Is this
> > considered a good practice?
> 
> Well, on MacOS and GNU/Linux, it wouldn't be necessary to install the
> font globally; instead, the Emacs binary can programmatically add a
> local directory to the list of font directories scanned by
> fontconfig.

Don't you also need to run fontconfig to pick that up?  Won't that be
a complication for users?

>   https://docs.microsoft.com/en-us/windows/win32/directwrite/custom-font-sets-win10

We don't (and won't) use DirectWrite.  We've switched to using
HarfBuzz, a free shaping engine, for that reason (and many others).

Anyway, I th9ink you understand by now that I dislike this idea, and
prefer to use image files.  Let's leave the characters and their
glyphs for what they were intended: text.

Re: High-res Customize icons

[Yuan Fu]

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


> In the patch I modified widget-image-find to look for @2x images. Can we even modify find-image so it looks for @2x images (as an opt-in feature)? That way Other applications (Magit, gdb-mi, etc) that uses images icons in buffer and fringe could have high-res icons without changing a line of code (assuming they use find-image).

Apart from the font vs image discussion, what about the idea to add @2x images support to Emacs? WDYT? Basically, we add name@2x.xpm <mailto:name@2x.xpm> images along side the existing name.xpm images. And find-image would prefer those @2x images if, say, image-prefer-hidpi is non-nil.

Yuan

[-- Attachment #2: Type: text/html, Size: 1160 bytes --]

Re: High-res Customize icons

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Thu, 23 Apr 2020 15:35:19 -0400
> Cc: Werner LEMBERG <wl@gnu.org>,
>  Juri Linkov <juri@linkov.net>,
>  Yuri Khan <yuri.v.khan@gmail.com>,
>  Clément Pit-Claudel <cpitclaudel@gmail.com>,
>  yandros@gmail.com,
>  emacs-devel@gnu.org
> 
> Apart from the font vs image discussion, what about the idea to add @2x images support to Emacs?
> WDYT? Basically, we add name@2x.xpm images along side the existing name.xpm images. And find-image
> would prefer those @2x images if, say, image-prefer-hidpi is non-nil.

I don't think I understand what is meant by @2x images, but the
general idea of preferring certain variants of images given some
aspect of the environment is sound.

Re: High-res Customize icons

[Yuan Fu]

> On Apr 23, 2020, at 3:40 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Thu, 23 Apr 2020 15:35:19 -0400
>> Cc: Werner LEMBERG <wl@gnu.org>,
>> Juri Linkov <juri@linkov.net>,
>> Yuri Khan <yuri.v.khan@gmail.com>,
>> Clément Pit-Claudel <cpitclaudel@gmail.com>,
>> yandros@gmail.com,
>> emacs-devel@gnu.org
>> 
>> Apart from the font vs image discussion, what about the idea to add @2x images support to Emacs?
>> WDYT? Basically, we add name@2x.xpm images along side the existing name.xpm images. And find-image
>> would prefer those @2x images if, say, image-prefer-hidpi is non-nil.
> 
> I don't think I understand what is meant by @2x images, but the
> general idea of preferring certain variants of images given some
> aspect of the environment is sound.

On HiDPI monitors you can essentially display 200x200 pixels on the same area where normal monitors can display 100x100 pixels, hence the @2x. Application icons nowadays normally comes with @2x and @3x variants. So a 32x32 icon also comes with 64x64 and 96x96 size. At least that’s how is goes for iOS and macOS apps. 

Yuan

Re: High-res Customize icons

[chad]

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

The KDE Breeze icon set (that was mentioned recently on emacs-devel as a
potential for the toolbar) also does this.

~Chad

On Thu, Apr 23, 2020 at 12:59 PM Yuan Fu <casouri@gmail.com> wrote:

>
>
> > On Apr 23, 2020, at 3:40 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >> From: Yuan Fu <casouri@gmail.com>
> >> Date: Thu, 23 Apr 2020 15:35:19 -0400
> >> Cc: Werner LEMBERG <wl@gnu.org>,
> >> Juri Linkov <juri@linkov.net>,
> >> Yuri Khan <yuri.v.khan@gmail.com>,
> >> Clément Pit-Claudel <cpitclaudel@gmail.com>,
> >> yandros@gmail.com,
> >> emacs-devel@gnu.org
> >>
> >> Apart from the font vs image discussion, what about the idea to add @2x
> images support to Emacs?
> >> WDYT? Basically, we add name@2x.xpm images along side the existing
> name.xpm images. And find-image
> >> would prefer those @2x images if, say, image-prefer-hidpi is non-nil.
> >
> > I don't think I understand what is meant by @2x images, but the
> > general idea of preferring certain variants of images given some
> > aspect of the environment is sound.
>
> On HiDPI monitors you can essentially display 200x200 pixels on the same
> area where normal monitors can display 100x100 pixels, hence the @2x.
> Application icons nowadays normally comes with @2x and @3x variants. So a
> 32x32 icon also comes with 64x64 and 96x96 size. At least that’s how is
> goes for iOS and macOS apps.
>
> Yuan

[-- Attachment #2: Type: text/html, Size: 2307 bytes --]

Re: High-res Customize icons

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Thu, 23 Apr 2020 15:59:46 -0400
> Cc: Werner LEMBERG <wl@gnu.org>,
>  Juri Linkov <juri@linkov.net>,
>  yuri.v.khan@gmail.com,
>  cpitclaudel@gmail.com,
>  yandros@gmail.com,
>  emacs-devel@gnu.org
> 
> On HiDPI monitors you can essentially display 200x200 pixels on the same area where normal monitors can display 100x100 pixels, hence the @2x. Application icons nowadays normally comes with @2x and @3x variants. So a 32x32 icon also comes with 64x64 and 96x96 size. At least that’s how is goes for iOS and macOS apps. 

Why not have only the largest image and show it in all the cases?

And with SVG, all those considerations are unnecessary, right?

Re: High-res Customize icons

[Dmitry Gutov]

On 24.04.2020 09:30, Eli Zaretskii wrote:
> Why not have only the largest image and show it in all the cases?

Downscaling usually results in loss of quality.

Re: High-res Customize icons

[chad]

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

On Thu, Apr 23, 2020 at 12:27 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > I think it is a good idea.  Today, OpenType fonts are standard on all
> > major platforms;
>
> That's not exactly why I asked whether it's a good idea.  I'm asking
> whether it's a good idea to use characters as if they were small
> images.  That is not what fonts were designed for, and that is
> definitely not what font-selection code in Emacs was designed for.
>

I know that you don't like the idea of using fonts for icons and emoji
inside emacs. I would ask you to reconsider, for two (and a half) reasons:

1.) This support us ubiquitous in the "modern" toolchains used by new
developers, especially in ubiquitous real-time chat systems, internet fora,
and the like. Anecdotally, I know emacs' lack of support for emoji (with
the additional refinement of support being added to and then removed from
emacs under macOS) has caused multiple smart coders to abandon emacs very
quickly.

2.) The all-the-icons package was created to consolidate multiple packages
that were installing these fonts for their own uses, especially packages
that update the mode line and the various file browsers (which is why
all-the-icons uses those screenshots specifically), and also MUA code. Put
another way, people are very likely to use some of these fonts inside emacs
anyway. The difference is in how much effort it takes -- whether they see
it mostly in packages like Spacemacs, Doom, and mu4e, or in "plain emacs".

2.5) These fonts are very popular amongst developers who use "fancy prompt"
packages for their shell, so that their prompt includes things like git
status, python/docker/ruby/etc env markers, battery indicators, and
similar. These features are pretty young (compared to most of us, anyway),
but are nigh-ubiquitous among newer developers I've seen; the features are
both built into many new shells and have spawned a surprisingly large
variety of "cool prompt" packages for a wide variety of shells (including
several for bash). I mention this as evidence that installing fonts is not
at all a high bar for most developers.

Anyway, I th9ink you understand by now that I dislike this idea, and
> prefer to use image files.  Let's leave the characters and their
> glyphs for what they were intended: text.
>

I fear/believe that the foals of those horses have already built themselves
new multicolored, ideogram-based barns out in the world. :-)

~Chad
P.S. ...and now I notice that this is pretty much the only communication
medium I regularly use that doesn't automatically convert that smiley into
an emoji... ...because I choose to have it off for this mailing list.

[-- Attachment #2: Type: text/html, Size: 3384 bytes --]

Re: High-res Customize icons

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Thu, 23 Apr 2020 16:23:27 -0700
> Cc: Werner LEMBERG <wl@gnu.org>, Juri Linkov <juri@linkov.net>, Yuan Fu <casouri@gmail.com>, 
> 	Yuri Khan <yuri.v.khan@gmail.com>, Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	EMACS development team <emacs-devel@gnu.org>
> 
> I know that you don't like the idea of using fonts for icons and emoji inside emacs. I would ask you to
> reconsider, for two (and a half) reasons:

Thanks.  I already did reconsider that, based on what was posted in
this thread, and my latest opinion is in the message I sent a few
minutes back, in response to Stefan's (and more about it below).

> 1.) This support us ubiquitous in the "modern" toolchains used by new developers, especially in ubiquitous
> real-time chat systems, internet fora, and the like. Anecdotally, I know emacs' lack of support for emoji (with
> the additional refinement of support being added to and then removed from emacs under macOS) has
> caused multiple smart coders to abandon emacs very quickly.
> 
> 2.) The all-the-icons package was created to consolidate multiple packages that were installing these fonts
> for their own uses, especially packages that update the mode line and the various file browsers (which is
> why all-the-icons uses those screenshots specifically), and also MUA code. Put another way, people are
> very likely to use some of these fonts inside emacs anyway. The difference is in how much effort it takes --
> whether they see it mostly in packages like Spacemacs, Doom, and mu4e, or in "plain emacs".
> 
> 2.5) These fonts are very popular amongst developers who use "fancy prompt" packages for their shell, so
> that their prompt includes things like git status, python/docker/ruby/etc env markers, battery indicators, and
> similar. These features are pretty young (compared to most of us, anyway), but are nigh-ubiquitous among
> newer developers I've seen; the features are both built into many new shells and have spawned a
> surprisingly large variety of "cool prompt" packages for a wide variety of shells (including several for bash). I
> mention this as evidence that installing fonts is not at all a high bar for most developers.

Those reasons are valid for third-party package developers.  As I
wrote, I understand very well why they are doing that.  Moreover, no
matter what I say, I cannot cause anyone to do things differently in
their own packages.  I won't even try.  People who like the results
are free to use those packages, they are free software.

But for core Emacs features we cannot be guided by convenience alone,
nor by the least-resistance pathways.  We must do it The Right Way,
the way that the technology dictates, the way that will not cause
clashes with other Emacs features and with future developments.

Take the example of the various ligature-using packages, which use the
prettify-symbols-mode.  Their popularity notwithstanding, this is the
wrong way of adding support for ligatures to Emacs.  It is wrong to
tell users to install a certain font or a bunch of fonts, and then
manually configure each ligature by peeking inside the font and
figuring out the glyph code for each ligature.  The right way of doing
that is to use a text-shaping engine which will work with the font to
produce the ligatures automatically.  Which is what we did when we
moved to HarfBuzz as our main text shaper.  Now ligatures are almost
free for having, we just need motivated individuals to figure out the
user-facing front-end and write some simple Lisp.

Yes, the prettify-symbols-mode way is "easier".  Yes, there are many
packages out there which use that.  No, it isn't TRT, because it
causes you to be married to a certain edition of a certain font.  To
say nothing of the fact that static compositions, which underly
prettify-symbols-mode, don't support bidirectional scripts, and so are
from the get-go obsolete technology that we shouldn't embrace for
novel features.

The bottom line is that IMO we should take technology and future
developments into consideration when we decide how to implement core
features in Emacs.  That something can be easily done today is not
necessarily the only or even the main reason for doing that in core
that very way.

It is possible that "by popular demand" we will eventually use
something like those fonts, regardless of what I think, but I don't
think we should.

> P.S. ...and now I notice that this is pretty much the only communication medium I regularly use that doesn't
> automatically convert that smiley into an emoji... ...because I choose to have it off for this mailing list. 

Not sure why, the Emacs email agents are perfectly capable of
displaying smileys, certainly with our use of HarfBuzz today.

Re: High-res Customize icons

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > That's not exactly why I asked whether it's a good idea.  I'm asking
  > whether it's a good idea to use characters as if they were small
  > images.

Could you state the issue more clearly?  In an abstract sense, a glyph
IS a small image.  You know that, so I suppose you refer to some more
specific, concrete issue, perhaps related specifically to how Emacs
redisplay works?

Could you please spell out that issue?

	     That is not what fonts were designed for,

If lots of programs use fonts for that job, I think we can
conclude their design is suitable for it.

						       and that is
  > definitely not what font-selection code in Emacs was designed for.

That could be an important issue.  I think it would depend on
just where Emacs would display the images, and for what purpose.

If they would appear within lines of text, I think it would not be
hard to change Emacs to display them more or less as if they were
characters.  That doesn't mean they have to be like characters at the
level of strings or buffers.

However, if they are not like characters at that level, we would
need to design some other Lisp-level spec for them.

  > > To conform to the standard, glyphs that are not in Unicode would be
  > > put into the PUA (Private User Area), again ensuring that there are no
  > > conflicts with other applications.

At what levels in the code of Emacs would it be necessary to use the PUA?

Would this be limited to communication with other components of the
operating system, such as Xlib or GTK?  If so, I think it would not
be a problem for Emacs to do this, if it is commonplace for other
programs to do this.

Or would this have to extend up into other levels of Emacs?

  > I'm very much against using PUA codepoints for this purpose (or any
  > purpose, really) in Emacs.

Could you explain?

				To say nothing of the fact that we
  > currently simply cannot.  That's a non-starter, from my POV.

What is the obstacle?  I think the key question is which levels of
Emacs the obstacle applies to.  Would the obstacle preclude using PUA
characters for low-level communication with Xlib or comparable
libraries?  If not, maybe we could represent the icons and emojis
some other way at higher levels.

It might be ok to do this with image files, but before rejecting the
idea of doing this with fonts, let's look at it carefully.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: High-res Customize icons

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: wl@gnu.org, juri@linkov.net, casouri@gmail.com,
> 	cpitclaudel@gmail.com, emacs-devel@gnu.org, yandros@gmail.com,
> 	yuri.v.khan@gmail.com
> Date: Fri, 24 Apr 2020 23:30:53 -0400
> 
>   > That's not exactly why I asked whether it's a good idea.  I'm asking
>   > whether it's a good idea to use characters as if they were small
>   > images.
> 
> Could you state the issue more clearly?

I think I did, in several messages posted since the one to which you
are responding.  I prefer to wait for you to read them, before we
continue this line of discussion, because I think I already explained
everything in those followup messages, and have nothing to add to that
on this general level.

> 	     That is not what fonts were designed for,
> 
> If lots of programs use fonts for that job, I think we can
> conclude their design is suitable for it.

I asked whether other programs do that, and if that is considered a
good idea.  The only reply I got seemed to suggest this is not
something program usually do or consider a good idea.  Which is what
I'd expect.

> 						       and that is
>   > definitely not what font-selection code in Emacs was designed for.
> 
> That could be an important issue.  I think it would depend on
> just where Emacs would display the images, and for what purpose.

As I said elsewhere, Emacs doesn't have such distinction.  Wherever a
character with a certain codepoint is needed, Emacs looks for a font
that can display that character.

> If they would appear within lines of text, I think it would not be
> hard to change Emacs to display them more or less as if they were
> characters.  That doesn't mean they have to be like characters at the
> level of strings or buffers.
> 
> However, if they are not like characters at that level, we would
> need to design some other Lisp-level spec for them.

AFAIU, they are indeed "not like characters".

>   > > To conform to the standard, glyphs that are not in Unicode would be
>   > > put into the PUA (Private User Area), again ensuring that there are no
>   > > conflicts with other applications.
> 
> At what levels in the code of Emacs would it be necessary to use the PUA?

I don't think I understand the question.  What are the "levels" to
consider in this context?

> Would this be limited to communication with other components of the
> operating system, such as Xlib or GTK?  If so, I think it would not
> be a problem for Emacs to do this, if it is commonplace for other
> programs to do this.
> 
> Or would this have to extend up into other levels of Emacs?

Again, I don't understand well what you mean by "levels" in this
context, but in a nutshell we will have to use these codepoints
everywhere where we use characters.

>   > I'm very much against using PUA codepoints for this purpose (or any
>   > purpose, really) in Emacs.
> 
> Could you explain?

Which part?

Re: High-res Customize icons

[Clément Pit-Claudel]

On 25/04/2020 03.02, Eli Zaretskii wrote:
> I asked whether other programs do that, and if that is considered a
> good idea.  The only reply I got seemed to suggest this is not
> something program usually do or consider a good idea.  Which is what
> I'd expect.

Sorry, I thought I had replied.
I'm not sure whether it's considered a good idea, but it's very common for programs implemented using web technologies (HTML, Javascript, CSS).
Traditionally, the many small bitmaps needed by a website were shipped as a single image concatenating all of them (called a CSS image sprite).  Lately, I've seen most websites move to the like of (the non-free icon set) fontawesome.
There's heavy debate in the web community about this topic (SVG vs icon fonts), but little of it applies to us, because it's mostly about browser support and delivery speeds.

A quick survey of editors, as far as I can tell from a quick look:
- Visual Studio Code use svg files
- Atom uses an icon font (octicon)
- SublimeText (non-free) uses png, with variants (labelled @2, @3) for high-dpi screens

Clément.

Re: High-res Customize icons

[Eli Zaretskii]

> Cc: wl@gnu.org, juri@linkov.net, casouri@gmail.com, emacs-devel@gnu.org,
>  yandros@gmail.com, yuri.v.khan@gmail.com
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Sat, 25 Apr 2020 08:37:53 -0400
> 
> On 25/04/2020 03.02, Eli Zaretskii wrote:
> > I asked whether other programs do that, and if that is considered a
> > good idea.  The only reply I got seemed to suggest this is not
> > something program usually do or consider a good idea.  Which is what
> > I'd expect.
> 
> Sorry, I thought I had replied.

You did.  Yours was the only response I alluded to.

Thanks.

Re: High-res Customize icons

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Tue, 21 Apr 2020 22:47:54 -0700
> Cc: EMACS development team <emacs-devel@gnu.org>
> 
> Worth noting: If I understand correctly, the toolbar buttons are not the same sort of emacs item as the
> Customize buttons; the former are restricted specifically to the toolbar (and maybe the tab-bar, now?), and
> use a traditional GUI update/repaint/etc method, whereas customize buttons appear in buffers, and have to
> deal with the redisplay engine, as well as needing to work in both terminal and various-gui frames. 

I think you mistakenly assume that tool-bar buttons always come from a
toolkit.  They aren't: Emacs is quite capable of drawing its own
built-in tool bar, and actually does this on MS-Windows (and in a
non-toolkit X build).  When that is how we show the tool bar, the
buttons there are very similar to the ones we show in Customize
buffers, except that we show images on the tool bar, something we
don't in the Customize buffers.

> It might be possible to use xwidgets to put gui toolkit buttons into
> buffers.

IMO, xwidgets are not sufficiently portable to use them as a basis for
prettier buttons.

Re: High-res Customize icons

[chad]

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

I wasn't assuming a toolkit, but I didn't think to call out the
differences, since the OP was asking about improving the display of
Customize under macOS (which I used extensively until around January of
last year). That same context is why I brought up xwidgets: because
nswxidget exists, but isn't really stable.

As it turns out, the OP was more concerned about the "icons" that are
probably better handled with fonts (similar to all-the-icons, org-bullets,
and prettify-symbols-mode) than the buttons and dropdown-menus I
(mistakenly) assumed.

While we're on the topic of portability, though: how (how well?) does the
support for older Windows versions handle these sort of fonts? It's been
decades since I had to look at code points, and that was mostly in the
context of European language translations rather than "icons" or emoji. In
particular, if the terminal doesn't support such fonts, does it degrade
reasonably? Empty rectangles? Boxed numbers?

Thanks in advance,
~Chad


On Wed, Apr 22, 2020 at 6:35 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: chad <yandros@gmail.com>
> > Date: Tue, 21 Apr 2020 22:47:54 -0700
> > Cc: EMACS development team <emacs-devel@gnu.org>
> >
> > Worth noting: If I understand correctly, the toolbar buttons are not the
> same sort of emacs item as the
> > Customize buttons; the former are restricted specifically to the toolbar
> (and maybe the tab-bar, now?), and
> > use a traditional GUI update/repaint/etc method, whereas customize
> buttons appear in buffers, and have to
> > deal with the redisplay engine, as well as needing to work in both
> terminal and various-gui frames.
>
> I think you mistakenly assume that tool-bar buttons always come from a
> toolkit.  They aren't: Emacs is quite capable of drawing its own
> built-in tool bar, and actually does this on MS-Windows (and in a
> non-toolkit X build).  When that is how we show the tool bar, the
> buttons there are very similar to the ones we show in Customize
> buffers, except that we show images on the tool bar, something we
> don't in the Customize buffers.
>
> > It might be possible to use xwidgets to put gui toolkit buttons into
> > buffers.
>
> IMO, xwidgets are not sufficiently portable to use them as a basis for
> prettier buttons.
>

[-- Attachment #2: Type: text/html, Size: 2904 bytes --]

Re: High-res Customize icons

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Wed, 22 Apr 2020 10:09:20 -0700
> Cc: Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	EMACS development team <emacs-devel@gnu.org>
> 
> As it turns out, the OP was more concerned about the "icons" that are probably better handled with fonts
> (similar to all-the-icons, org-bullets, and prettify-symbols-mode) than the buttons and dropdown-menus I
> (mistakenly) assumed.
> 
> While we're on the topic of portability, though: how (how well?) does the support for older Windows versions
> handle these sort of fonts? It's been decades since I had to look at code points, and that was mostly in the
> context of European language translations rather than "icons" or emoji. In particular, if the terminal doesn't
> support such fonts, does it degrade reasonably? Empty rectangles? Boxed numbers?

We don't use fonts for the icons, so I don't think I understand the
question.

If a font is not available for some character, Emacs will by default
show a box with a hex code.  That happens on any platform, not just on
Windows.

But for icons, we use small images, and we use the libxpm library to
show them.

Re: High-res Customize icons

[chad]

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

On Wed, Apr 22, 2020 at 10:37 AM Eli Zaretskii <eliz@gnu.org> wrote:

>
> We don't use fonts for the icons, so I don't think I understand the
> question.
>

I think messages are crossing in-flight. The recent suggestion in the
thread was that the right-triangle-bullet the OP wants to improve in
Customize could be implemented nicely with such an font.

From: Yuri Khan

>  I wonder if it’s even worthwhile having a bitmap for this. These days, it
> could as well be any of ▶/▼, ▷/▽, ▸/▾, or ▹/▿. It would even work on some
> text terminals.


HTH,
~Chad

[-- Attachment #2: Type: text/html, Size: 1203 bytes --]

Re: High-res Customize icons

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Wed, 22 Apr 2020 11:28:11 -0700
> Cc: Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	EMACS development team <emacs-devel@gnu.org>
> 
>  We don't use fonts for the icons, so I don't think I understand the
>  question.
> 
> I think messages are crossing in-flight. The recent suggestion in the thread was that the right-triangle-bullet
> the OP wants to improve in Customize could be implemented nicely with such an font.
> 
> From: Yuri Khan
> 
>   I wonder if it’s even worthwhile having a bitmap for this. These days, it could as well be any of ▶/▼,
>  ▷/▽, ▸/▾, or ▹/▿. It would even work on some text terminals.

Bad idea, IMO.

Re: High-res Customize icons

[Yuan Fu]

> On Apr 22, 2020, at 2:38 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: chad <yandros@gmail.com>
>> Date: Wed, 22 Apr 2020 11:28:11 -0700
>> Cc: Clément Pit-Claudel <cpitclaudel@gmail.com>, 
>> 	EMACS development team <emacs-devel@gnu.org>
>> 
>> We don't use fonts for the icons, so I don't think I understand the
>> question.
>> 
>> I think messages are crossing in-flight. The recent suggestion in the thread was that the right-triangle-bullet
>> the OP wants to improve in Customize could be implemented nicely with such an font.
>> 
>> From: Yuri Khan
>> 
>>  I wonder if it’s even worthwhile having a bitmap for this. These days, it could as well be any of ▶/▼,
>> ▷/▽, ▸/▾, or ▹/▿. It would even work on some text terminals.
> 
> Bad idea, IMO.
> 

Why a bad idea? I’m curious to know. From what I can see, unicode glyphs looks pretty good and comes for free, and as Yuri said they could even work on text terminals. At least for the simple shapes like ▶/▼, they seems to be a good option.

BTW, as for the location of the code that inserts those icons, I’ve found them in cus-edit.el. They are inserted by custom-visibility widget (using widget-image-insert).

Yuan

Re: High-res Customize icons

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Wed, 22 Apr 2020 15:19:16 -0400
> Cc: chad <yandros@gmail.com>,
>  Clément Pit-Claudel <cpitclaudel@gmail.com>,
>  emacs-devel@gnu.org
> 
> >>  I wonder if it’s even worthwhile having a bitmap for this. These days, it could as well be any of ▶/▼,
> >> ▷/▽, ▸/▾, or ▹/▿. It would even work on some text terminals.
> > 
> > Bad idea, IMO.
> 
> Why a bad idea? I’m curious to know.

Because you basically cannot trust different fonts to look the same,
or even similar enough, and because some fonts will not have the glyph
for those characters, which means complications.  It's tempting to use
a special character, because it's easy, but it's a false hope, it only
makes things more complicated.

> From what I can see, unicode glyphs looks pretty good and comes for free, and as Yuri said they could even work on text terminals. At least for the simple shapes like ▶/▼, they seems to be a good option.

We cannot base fundamental features of the Emacs UI on techniques that
_might_ work.  We need techniques that _always_ work.

Re: High-res Customize icons

[Yuan Fu]

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



> On Apr 22, 2020, at 3:28 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Wed, 22 Apr 2020 15:19:16 -0400
>> Cc: chad <yandros@gmail.com>,
>> Clément Pit-Claudel <cpitclaudel@gmail.com>,
>> emacs-devel@gnu.org
>> 
>>>> I wonder if it’s even worthwhile having a bitmap for this. These days, it could as well be any of ▶/▼,
>>>> ▷/▽, ▸/▾, or ▹/▿. It would even work on some text terminals.
>>> 
>>> Bad idea, IMO.
>> 
>> Why a bad idea? I’m curious to know.
> 
> Because you basically cannot trust different fonts to look the same,
> or even similar enough, and because some fonts will not have the glyph
> for those characters, which means complications.  It's tempting to use
> a special character, because it's easy, but it's a false hope, it only
> makes things more complicated.
> 
>> From what I can see, unicode glyphs looks pretty good and comes for free, and as Yuri said they could even work on text terminals. At least for the simple shapes like ▶/▼, they seems to be a good option.
> 
> We cannot base fundamental features of the Emacs UI on techniques that
> _might_ work.  We need techniques that _always_ work.

I agree.

Here is a patch for the high-res icons. Put both icon files under /etc/images/custom.

In the patch I modified widget-image-find to look for @2x images. Can we even modify find-image so it looks for @2x images (as an opt-in feature)? That way Other applications (Magit, gdb-mi, etc) that uses images icons in buffer and fringe could have high-res icons without changing a line of code (assuming they use find-image).

low-res

[-- Attachment #2: Screen Shot 2020-04-22 at 4.30.55 PM.png --]
[-- Type: image/png, Size: 62000 bytes --]

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



high-res

[-- Attachment #4: Screen Shot 2020-04-22 at 4.31.27 PM.png --]
[-- Type: image/png, Size: 61476 bytes --]

[-- Attachment #5: Type: text/plain, Size: 8 bytes --]



Yuan


[-- Attachment #6: high-res.patch --]
[-- Type: application/octet-stream, Size: 1146 bytes --]

diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
index 284fd1d6cb..62a6079637 100644
--- a/lisp/wid-edit.el
+++ b/lisp/wid-edit.el
@@ -603,6 +603,11 @@ widget-image-conversion
 		       (repeat :tag "Suffixes"
 			       (string :format "%v")))))
 
+(defcustom widget-high-res-icon t
+  "If non-nil, Emacs tries to use high resolution icons in widgets."
+  :group 'widgets
+  :type 'boolean)
+
 (defun widget-image-find (image)
   "Create a graphical button from IMAGE.
 IMAGE should either already be an image, or be a file name sans
@@ -619,6 +624,13 @@ widget-image-find
 	 ;; A string.  Look it up in relevant directories.
 	 (let* ((load-path (cons widget-image-directory load-path))
 		specs)
+           (if widget-high-res-icon
+               (dolist (elt widget-image-conversion)
+	         (dolist (ext (cdr elt))
+	           (push (list :type (car elt)
+                               :file (concat image "@2x" ext)
+                               :scale 0.5)
+                         specs))))
 	   (dolist (elt widget-image-conversion)
 	     (dolist (ext (cdr elt))
 	       (push (list :type (car elt) :file (concat image ext))

[-- Attachment #7: righ@2x.xpm --]
[-- Type: application/octet-stream, Size: 556 bytes --]

/* XPM */
static char *righ_2x[] = {
/* columns rows colors chars-per-pixel */
"18 18 4 1 ",
"  c black",
". c gray45",
"X c white",
"o c None",
/* pixels */
"     ooooooooooooo",
"       ooooooooooo",
"  ...    ooooooooo",
"  X...     ooooooo",
"  XXX...     ooooo",
"  XXXXX...     ooo",
"  XXXXXXX...     o",
"  XXXXXXXXX...    ",
"  XXXXXXXXXXX...  ",
"  XXXXXXXXXXX...  ",
"  XXXXXXXXX...    ",
"  XXXXXXX...     o",
"  XXXXX...     ooo",
"  XXX....    ooooo",
"  X...     ooooooo",
"  ...    ooooooooo",
"       ooooooooooo",
"     ooooooooooooo"
};

[-- Attachment #8: down@2x.xpm --]
[-- Type: application/octet-stream, Size: 556 bytes --]

/* XPM */
static char *down_2x[] = {
/* columns rows colors chars-per-pixel */
"18 18 4 1 ",
"  c black",
". c gray45",
"X c white",
"o c None",
/* pixels */
"                  ",
"                  ",
"  .XXXXXXXXXXXX.  ",
"  ..XXXXXXXXXX..  ",
"  ..XXXXXXXXXX..  ",
"o  ..XXXXXXXX..  o",
"o   .XXXXXXXX.   o",
"oo  ..XXXXXX..  oo",
"oo   .XXXXXX.   oo",
"ooo  ..XXXX..  ooo",
"ooo   .XXXX.   ooo",
"oooo  ..XX..  oooo",
"oooo   .XX.   oooo",
"ooooo  ....  ooooo",
"ooooo   ..   ooooo",
"oooooo  ..  oooooo",
"oooooo      oooooo",
"ooooooo    ooooooo"
};

[-- Attachment #9: Type: text/plain, Size: 4 bytes --]

Re: High-res Customize icons

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Wed, 22 Apr 2020 16:38:10 -0400
> Cc: yandros@gmail.com,
>  cpitclaudel@gmail.com,
>  emacs-devel@gnu.org
> 
> Here is a patch for the high-res icons. Put both icon files under /etc/images/custom.
> 
> In the patch I modified widget-image-find to look for @2x images. Can we even modify find-image so it looks for @2x images (as an opt-in feature)? That way Other applications (Magit, gdb-mi, etc) that uses images icons in buffer and fringe could have high-res icons without changing a line of code (assuming they use find-image).

I think Emacs should look in the hi-res subdirectory when the display
is high resolution.  A defcustom sounds like a wrong way to handle
this issue.

Re: High-res Customize icons

[Yuan Fu]

> On May 1, 2020, at 9:46 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Wed, 22 Apr 2020 16:38:10 -0400
>> Cc: yandros@gmail.com,
>> cpitclaudel@gmail.com,
>> emacs-devel@gnu.org
>> 
>> Here is a patch for the high-res icons. Put both icon files under /etc/images/custom.
>> 
>> In the patch I modified widget-image-find to look for @2x images. Can we even modify find-image so it looks for @2x images (as an opt-in feature)? That way Other applications (Magit, gdb-mi, etc) that uses images icons in buffer and fringe could have high-res icons without changing a line of code (assuming they use find-image).
> 
> I think Emacs should look in the hi-res subdirectory when the display
> is high resolution.  A defcustom sounds like a wrong way to handle
> this issue.

That could work too, so we will have images@2x and images@3x in addition to the current images directory?

Yuan

Re: High-res Customize icons

[Yuan Fu]

> On May 1, 2020, at 9:46 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Wed, 22 Apr 2020 16:38:10 -0400
>> Cc: yandros@gmail.com,
>> cpitclaudel@gmail.com,
>> emacs-devel@gnu.org
>> 
>> Here is a patch for the high-res icons. Put both icon files under /etc/images/custom.
>> 
>> In the patch I modified widget-image-find to look for @2x images. Can we even modify find-image so it looks for @2x images (as an opt-in feature)? That way Other applications (Magit, gdb-mi, etc) that uses images icons in buffer and fringe could have high-res icons without changing a line of code (assuming they use find-image).
> 
> I think Emacs should look in the hi-res subdirectory when the display
> is high resolution.  A defcustom sounds like a wrong way to handle
> this issue.

Thinking more about this, a hi-res subdirectory is useful for organizing files, but shouldn’t be used for determining where to find high-res images. I suppose you mean to have separate image-load-path and high-res-image-load-path? That would be inconvenient for package authors, if they want to use image in their package, they need to create two subdirectories for high and low resolution image, add them to the two load-path, and use find-image. OTOH, if we use a single image load-path and search for the @2x variant before the regular image, package authors only need to name their images img.png and img@2x.png, and put them under the package directory (since package directory is already in load-path). 

That’s about how to find the high-res variant of an image, determining whether we want to use a high-res variant is another story. On hidpi screens, the OS tells you the resolution of an area is 100x100, but the physical pixels in that area could be in fact 200x200. That’s why an 100x100 image looks blurry. I don’t think there is a reliable way to tell the current screen’s pixel density. So I think a custom option is the most reliable and stable approach. If the user wants this, they just set that variable.

Concretely, I mean a custom option like this:

(defcustom image-resolution-scaling-factor 1
  "If greater than 1, try display high-res alternatives.
E.g., if the value is 2, `find-image' tries to find file@2x.png
for file.png."
  :type '(choice number
                 (const :tag "1x" 1)
                 (const :tag "2x" 2)
                 (const :tag "3x" 3))
  :version "28.1")

Yuan

Re: High-res Customize icons

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Fri, 23 Oct 2020 12:39:44 -0400
> Cc: chad <yandros@gmail.com>,
>  cpitclaudel@gmail.com,
>  emacs-devel@gnu.org
> 
> (defcustom image-resolution-scaling-factor 1
>   "If greater than 1, try display high-res alternatives.
> E.g., if the value is 2, `find-image' tries to find file@2x.png
> for file.png."
>   :type '(choice number
>                  (const :tag "1x" 1)
>                  (const :tag "2x" 2)
>                  (const :tag "3x" 3))
>   :version "28.1")

The reason I said defcustom didn't sound like TRT was because I think
Emacs should handle this automatically.  It should automatically load
the high resolution images when appropriate.  Where it finds those
images and by what logic is a secondary question.

Re: High-res Customize icons

[Yuan Fu]

> 
> The reason I said defcustom didn't sound like TRT was because I think
> Emacs should handle this automatically.  It should automatically load
> the high resolution images when appropriate.  Where it finds those
> images and by what logic is a secondary question.
> 

I dug a bit further and it seems to do with Cocoa on Mac. On other engines the resolution is simply the resolution of the monitor, but Cocoa add an abstraction layer and the resolution an applications detects aren’t the actual physical resolution.

So for high-res icons we want to simply use the @2x image on Linux and use @2x image but with :scale 0.5 on Cocoa. If we use normal image on high-res monitor, the image is too small on Linux, and if we are on Cocoa, the image is blurry.

To detect high-res screens on other platforms, we currently have a function that measures the pixel height of a default line: if it’s greater than 15 pixels, we consider the screen high-res and find-image will scale the returned image by :scale 2.

Cocoa provides an API for querying the scaling factor, if it is 2, we should load the @2x image and add :scale 0.5.

It’s kind of a mess. What do you think?

How about exposing that Cocoa API to lisp and handle accordingly in find-image? Some thing like:

(let (img)
  (if (eq (window-system) 'ns)
      ;; Cocoa
      (let ((pixel-scaling-factor (ns-scaling-factor)))
        (if (> pixel-scaling-factor 1.0)
            (append (find-2x-image) '(:scale 0.5))
          (find-normal-image)))
    ;; Other
    (let ((image-scaling-factor (image-compute-scaling-factor
                                 image-scaling-factor)))
      (if (> image-scaling-factor 2)
          (append (find-2x-image) '(:scale 2))
        (find-normal-image)))))


Yuan

Re: High-res Customize icons

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Tue, 27 Oct 2020 15:17:37 -0400
> Cc: chad <yandros@gmail.com>,
>  Clément Pit-Claudel <cpitclaudel@gmail.com>,
>  emacs-devel@gnu.org
> 
> How about exposing that Cocoa API to lisp and handle accordingly in find-image? Some thing like:
> 
> (let (img)
>   (if (eq (window-system) 'ns)
>       ;; Cocoa
>       (let ((pixel-scaling-factor (ns-scaling-factor)))
>         (if (> pixel-scaling-factor 1.0)
>             (append (find-2x-image) '(:scale 0.5))
>           (find-normal-image)))
>     ;; Other
>     (let ((image-scaling-factor (image-compute-scaling-factor
>                                  image-scaling-factor)))
>       (if (> image-scaling-factor 2)
>           (append (find-2x-image) '(:scale 2))
>         (find-normal-image)))))

I don't think I understand this well enough to answer the question.
Perhaps Alan could chime in and comment.

Re: High-res Customize icons

[Alan Third]

On Tue, Oct 27, 2020 at 03:17:37PM -0400, Yuan Fu wrote:
> 
> Cocoa provides an API for querying the scaling factor, if it is 2,
> we should load the @2x image and add :scale 0.5.
> 
> It’s kind of a mess. What do you think?
> 
> How about exposing that Cocoa API to lisp and handle accordingly in
> find-image? Some thing like:

This sounds good to me. It should be easy to expose the scale factor
to lisp. The only potential problem is that it can change as the frame
is dragged from one screen to the other, or similar. Is there any way
to force reloading the images?

Anyway, even if not it will always display something, just not
necessarily the optimal image.

Do you want me to write the C code to expose the scale factor?
-- 
Alan Third

Re: High-res Customize icons

[Yuan Fu]

> On Oct 27, 2020, at 6:26 PM, Alan Third <alan@idiocy.org> wrote:
> 
> On Tue, Oct 27, 2020 at 03:17:37PM -0400, Yuan Fu wrote:
>> 
>> Cocoa provides an API for querying the scaling factor, if it is 2,
>> we should load the @2x image and add :scale 0.5.
>> 
>> It’s kind of a mess. What do you think?
>> 
>> How about exposing that Cocoa API to lisp and handle accordingly in
>> find-image? Some thing like:
> 
> This sounds good to me. It should be easy to expose the scale factor
> to lisp. The only potential problem is that it can change as the frame
> is dragged from one screen to the other, or similar. Is there any way
> to force reloading the images?

At least it doesn’t introduce regression. And we probably don’t want Emacs on Cocoa to perform better than that on Linux anyway. (Does anyone know what happens if you move Emacs from high-res screen to a low-res one on Linux?)

How should the variable be named? There is already a variable named image-scale-factor. I suggest something like ns-pixel-scale-factor.

> 
> Anyway, even if not it will always display something, just not
> necessarily the optimal image.
> 
> Do you want me to write the C code to expose the scale factor?

That’s marvelous!

Yuan

Re: High-res Customize icons

[Alan Third]

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

On Tue, Oct 27, 2020 at 07:09:02PM -0400, Yuan Fu wrote:
> 
> How should the variable be named? There is already a variable named
> image-scale-factor. I suggest something like ns-pixel-scale-factor.

I went with ns-frame-scale-factor as that matched some other frame
related functions.

> > Anyway, even if not it will always display something, just not
> > necessarily the optimal image.
> > 
> > Do you want me to write the C code to expose the scale factor?
> 
> That’s marvelous!

Attached. It appears to work on my retina laptop.
-- 
Alan Third

[-- Attachment #2: 0001-Expose-NS-frames-scale-factor-to-lisp.patch --]
[-- Type: text/plain, Size: 1572 bytes --]

From 094cbd60523ba9282b653d71c288776713812b2b Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Tue, 27 Oct 2020 23:53:13 +0000
Subject: [PATCH] Expose NS frames scale factor to lisp

* src/nsfns.m (Fns_frame_scale_factor): New function.
---
 src/nsfns.m | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/src/nsfns.m b/src/nsfns.m
index c7956497c4..7e367b0edb 100644
--- a/src/nsfns.m
+++ b/src/nsfns.m
@@ -1503,6 +1503,23 @@ Frames are listed from topmost (first) to bottommost (last).  */)
     }
 }
 
+DEFUN ("ns-frame-scale-factor", Fns_frame_scale_factor, Sns_frame_scale_factor,
+       0, 1, 0,
+       doc: /* Get the scale factor for FRAME.  */)
+  (Lisp_Object frame)
+{
+  struct frame *f = decode_window_system_frame (frame);
+
+#if defined NS_IMPL_COCOA && MAC_OS_X_VERSION_MAX_ALLOWED >= 1070
+  NSWindow *w = [FRAME_NS_VIEW (f) window];
+# if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
+  if ([w respondsToSelector:@selector(backingScaleFactor)])
+# endif
+    return make_float ([w backingScaleFactor]);
+#endif
+  return make_float (1);
+}
+
 DEFUN ("ns-popup-font-panel", Fns_popup_font_panel, Sns_popup_font_panel,
        0, 1, "",
        doc: /* Pop up the font panel.  */)
@@ -3133,6 +3150,7 @@ - (Lisp_Object)lispString
   defsubr (&Sns_frame_edges);
   defsubr (&Sns_frame_list_z_order);
   defsubr (&Sns_frame_restack);
+  defsubr (&Sns_frame_scale_factor);
   defsubr (&Sns_set_mouse_absolute_pixel_position);
   defsubr (&Sns_mouse_absolute_pixel_position);
   defsubr (&Sns_show_character_palette);
-- 
2.26.1

Re: High-res Customize icons

[YAMAMOTO Mitsuharu]

On Wed, 28 Oct 2020 04:17:37 +0900,
Yuan Fu wrote:
>
> I dug a bit further and it seems to do with Cocoa on Mac. On other engines the resolution is simply the resolution of the monitor, but Cocoa add an abstraction layer and the resolution an applications detects aren’t the actual physical resolution.
> 
> So for high-res icons we want to simply use the @2x image on Linux and use @2x image but with :scale 0.5 on Cocoa. If we use normal image on high-res monitor, the image is too small on Linux, and if we are on Cocoa, the image is blurry.
> 
> To detect high-res screens on other platforms, we currently have a function that measures the pixel height of a default line: if it’s greater than 15 pixels, we consider the screen high-res and find-image will scale the returned image by :scale 2.
> 
> Cocoa provides an API for querying the scaling factor, if it is 2, we should load the @2x image and add :scale 0.5.
> 
> It’s kind of a mess. What do you think?
>
> How about exposing that Cocoa API to lisp and handle accordingly in find-image? Some thing like:
> 
> (let (img)
>   (if (eq (window-system) 'ns)
>       ;; Cocoa
>       (let ((pixel-scaling-factor (ns-scaling-factor)))
>         (if (> pixel-scaling-factor 1.0)
>             (append (find-2x-image) '(:scale 0.5))
>           (find-normal-image)))
>     ;; Other
>     (let ((image-scaling-factor (image-compute-scaling-factor
>                                  image-scaling-factor)))
>       (if (> image-scaling-factor 2)
>           (append (find-2x-image) '(:scale 2))
>         (find-normal-image)))))


The Mac port (not the NS port) has supported @2x images since 2012 at
the C level as opposed to the Lisp level.  It also automatically
re-renders images in resolution-independent formats such as SVG or PDF
in reaction to the frame movement from a Retina display to a
non-Retina one, for example.  You might want to look at the
corresponding part of the Info document for the Mac port:

https://bitbucket.org/mituharu/emacs-mac/src/dfb5869abf8f6892e928042e9f8221f8435a0dcb/doc/emacs/macport.texi#lines-446

Althogh the backing scale factor information is not necessary at the
Lisp level for the automatic bitmap selection for the Mac port, it is
available via display-monitor-attributes-list (or
frame-monitor-attributes if you want to specify the frame to be
examined) as it is considered as a monitor-specific property.

    (pp (display-monitor-attributes-list))
    (((geometry 0 0 2560 1440)
      (workarea 0 23 2560 1337)
      (mm-size 599 340)
      (frames #<frame Emacs@YAMAMOTO-no-iMac-5K.local 0x7faa96927200>)
      (name . "iMac")
      (metal-device-name . "AMD Radeon R9 M380")
      (backing-scale-factor . 2))
     ((geometry 2560 0 1920 1200)
      (workarea 2560 23 1920 1177)
      (mm-size 493 311)
      (frames)
      (name . "Cinema HD")
      (metal-device-name . "AMD Radeon R9 M380")
      (backing-scale-factor . 1)))

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

Re: High-res Customize icons

[Yuan Fu]

> 
> The Mac port (not the NS port) has supported @2x images since 2012 at
> the C level as opposed to the Lisp level.  It also automatically
> re-renders images in resolution-independent formats such as SVG or PDF
> in reaction to the frame movement from a Retina display to a
> non-Retina one, for example.  You might want to look at the
> corresponding part of the Info document for the Mac port:
> 
> https://bitbucket.org/mituharu/emacs-mac/src/dfb5869abf8f6892e928042e9f8221f8435a0dcb/doc/emacs/macport.texi#lines-446
> 

This is very impressive. The NS port renders SVG in low resolution, but I don’t use SVG’s frequent enough to complain about it ;-) I wonder what’s the current behavior on changing resolution on a Linux display, and how should this image resolution thing work in general? Hopefully some expert in Linux xterm can chime in and provide some input.

Yuan

Re: High-res Customize icons

[ndame]

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

> It should be straightforward to take a free font family, strip all
> other glyphs, and modify the remaining symbols to make them fit.

Actually, there is an emacs package already which collects fonts
with free license to provide icons:

https://github.com/domtronn/all-the-icons.el

Check out the screenshot, e.g. the mode line at the bottom which looks quite nice:

https://raw.githubusercontent.com/domtronn/all-the-icons.el/master/logo.png

It would be nice if emacs shipped with these fonts and actually used the icons at various
places like on the screenshot.

[-- Attachment #2: Type: text/html, Size: 929 bytes --]

Re: High-res Customize icons

[ndame]

>
> Actually, there is an emacs package already which collects fonts
> with free license to provide icons:
>
> https://github.com/domtronn/all-the-icons.el

And the package even provides a way to automatically select the proper icon by
filetype, etc.

Re: High-res Customize icons

[Stefan Kangas]

ndame <ndame@protonmail.com> writes:

> Actually, there is an emacs package already which collects fonts
> with free license to provide icons:
>
> https://github.com/domtronn/all-the-icons.el
>
> Check out the screenshot, e.g. the mode line at the bottom which looks quite nice:
>
> https://raw.githubusercontent.com/domtronn/all-the-icons.el/master/logo.png
>
> It would be nice if emacs shipped with these fonts and actually used the icons at various
> places like on the screenshot.

This would be very nice indeed.  Is the idea technically sound?  If
so, it would open up a lot of doors for creating a much more beautiful
default Emacs experience, at least on graphical displays.

It seems to me that we should be able to work around the copyright
issues here.  There are 41 contributors to the all-the-icons package
according to GitHub.  Ideally, we would be able to procure assignments
from anyone with more than 15 lines of code contributed.  But the
Emacs Lisp library itself doesn't seem to be a lot of code, and could
possibly be rewritten by us if we fail to sort the assignments.

The main thing would be the fonts, which seem to have free licenses:
https://github.com/domtronn/all-the-icons.el#resource-fonts

AFAIU the fonts wouldn't need copyright assignments if they're only
"shipped with" (and not "part of") Emacs.

Best regards,
Stefan Kangas

Re: High-res Customize icons

[Stefan Kangas]

Stefan Kangas <stefan@marxist.se> writes:

> > Actually, there is an emacs package already which collects fonts
> > with free license to provide icons:
> >
> > https://github.com/domtronn/all-the-icons.el
> >
> > Check out the screenshot, e.g. the mode line at the bottom which looks quite nice:
> >
> > https://raw.githubusercontent.com/domtronn/all-the-icons.el/master/logo.png
> >
> > It would be nice if emacs shipped with these fonts and actually used the icons at various
> > places like on the screenshot.
>
> This would be very nice indeed.  Is the idea technically sound?  If
> so, it would open up a lot of doors for creating a much more beautiful
> default Emacs experience, at least on graphical displays.

Thinking about this a bit more, why did they choose to package the
icons up as ttf fonts instead of just including them as image files?
Is there any benefit to doing it that way?

Best regards,
Stefan Kangas

Re: High-res Customize icons

[Stefan Kangas]

Stefan Kangas <stefan@marxist.se> writes:

> > This would be very nice indeed.  Is the idea technically sound?  If
> > so, it would open up a lot of doors for creating a much more beautiful
> > default Emacs experience, at least on graphical displays.
>
> Thinking about this a bit more, why did they choose to package the
> icons up as ttf fonts instead of just including them as image files?
> Is there any benefit to doing it that way?

I just realized that his will allow you to change the color of the
icons.  Duh.  So that's a pretty nice idea, I guess.

Best regards,
Stefan Kangas

Re: High-res Customize icons

[Clément Pit-Claudel]

On 23/04/2020 10.11, Stefan Kangas wrote:
> Stefan Kangas <stefan@marxist.se> writes:
>> Thinking about this a bit more, why did they choose to package the
>> icons up as ttf fonts instead of just including them as image files?
>> Is there any benefit to doing it that way?
> 
> I just realized that his will allow you to change the color of the
> icons.  Duh.  So that's a pretty nice idea, I guess.

More importantly, images currently don't work nearly as nicely as icon fonts (you can change the color of images too, but transparency doesn't work well, etc.). As Juri wrote recently:

On 22/04/2020 17.12, Juri Linkov wrote:
> This is why the tab-bar moved from Unicode characters to images,
> but another attempt to use SVG failed as was demonstrated in
> https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00414.html

Re: High-res Customize icons

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> Thinking about this a bit more, why did they choose to package the
>> icons up as ttf fonts instead of just including them as image files?
>> Is there any benefit to doing it that way?
>
> I just realized that his will allow you to change the color of the
> icons.  Duh.  So that's a pretty nice idea, I guess.

Fonts are vectors graphics (well, these are), so you can scale them
without them turning blocky/smudgy.  I think that's the most important
reason for using fonts instead of images.

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

Re: High-res Customize icons

[Clément Pit-Claudel]

On 23/04/2020 10.46, Lars Ingebrigtsen wrote:
> Stefan Kangas <stefan@marxist.se> writes:
> 
>>> Thinking about this a bit more, why did they choose to package the
>>> icons up as ttf fonts instead of just including them as image files?
>>> Is there any benefit to doing it that way?
>>
>> I just realized that his will allow you to change the color of the
>> icons.  Duh.  So that's a pretty nice idea, I guess.
> 
> Fonts are vectors graphics (well, these are), so you can scale them
> without them turning blocky/smudgy.  I think that's the most important
> reason for using fonts instead of images.

Instead of bitmap images, but not instead of e.g. SVG images.
(And images are easier to customize for users)

Re: High-res Customize icons

[Stefan Monnier]

> Instead of bitmap images, but not instead of e.g. SVG images.
> (And images are easier to customize for users)

But SVG support is a lot more problematic than fonts support.
Both in practice and in theory (the theory part being that AFAIK the
definition of SVG includes the whole of HTML5, including Javascript and
the rest of the kitchen sink).

I don't know of any no good widely supported vector graphics format
that's not terribly complex.


        Stefan

Re: High-res Customize icons

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 23 Apr 2020 11:44:03 -0400
> Cc: emacs-devel@gnu.org
> 
> But SVG support is a lot more problematic than fonts support.
> Both in practice and in theory (the theory part being that AFAIK the
> definition of SVG includes the whole of HTML5, including Javascript and
> the rest of the kitchen sink).
> 
> I don't know of any no good widely supported vector graphics format
> that's not terribly complex.

Why should we care how complex is the format.  We are not going to
reimplement librsvg, that's why we use that library.  As long as the
library we use can handle whatever complexity needs to be handled, we
are home free.

I understand that it's tempting to use fonts because of simplicity,
but we should resist that temptation, IMO.  The alternative is not too
hard to use, and it's the right way of doing this stuff.

Re: High-res Customize icons

[Stefan Monnier]

>> I don't know of any no good widely supported vector graphics format
>> that's not terribly complex.
> Why should we care how complex is the format.

We don't.  But the complexity is often linked to the presence of
practical problems (e.g. lack of a good Free implementation, or lack of
a good multi-OS implementation, security bugs, performance cost, ...).

> I understand that it's tempting to use fonts because of simplicity,
> but we should resist that temptation, IMO.  The alternative is not too
> hard to use, and it's the right way of doing this stuff.

Other than the problems already mentioned with our SVG support, there's
also the fact that we don't have any way currently to auto-scale an
image according to the current face nor do we support using different
sizes for the same image displayed simultaneously in different frames.

So for "little images" in the modelines or in "list buffers" (like
dired), using special characters instead of actual images makes a lot of
sense (I suspect that it can be also significantly more efficient both
in memory and CPU use, but I don't actually know it to be the case).


        Stefan

Re: High-res Customize icons

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: cpitclaudel@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 23 Apr 2020 16:33:05 -0400
> 
> Other than the problems already mentioned with our SVG support, there's
> also the fact that we don't have any way currently to auto-scale an
> image according to the current face nor do we support using different
> sizes for the same image displayed simultaneously in different frames.

Then let's develop these facilities.  It shouldn't be hard, we already
have most of the infrastructure for scaling images.

It is IMO wrong to revert to tricks instead of adding the required
infrastructure to TDRT.  I can understand why authors of third-party
packages, who can only work in Lisp, use these tricks, but we
shouldn't base core features on such tricks.  They will cause us
trouble down the road.  E.g., what do you think about this advice on
the all-the-icons site:

  (set-fontset-font t 'unicode (font-spec :family "all-the-icons") nil 'append)

Do we really want to tell users to do that?  I shudder by just
thinking what font-related bug reports this will cause.

It's simply wrong to use fonts for these matters.  I very much hope
that we don't go down this road.  FWIW.

Re: High-res Customize icons

[Stefan Monnier]

> It's simply wrong to use fonts for these matters.  I very much hope
> that we don't go down this road.  FWIW.

Using fonts for those things has problems, yes.  Using images has
problems as well.

I'm not sure which is more wrong, and I think it very much depends on
the specific use cases.  And I think the boundary between the two is
likely to move over time, seeing how Unicode is integrating ever more
icons under the name "emoji".


        Stefan

Re: High-res Customize icons

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: cpitclaudel@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 24 Apr 2020 09:06:35 -0400
> 
> > It's simply wrong to use fonts for these matters.  I very much hope
> > that we don't go down this road.  FWIW.
> 
> Using fonts for those things has problems, yes.  Using images has
> problems as well.
> 
> I'm not sure which is more wrong, and I think it very much depends on
> the specific use cases.

We are talking about specific use cases, not in general.

> And I think the boundary between the two is likely to move over
> time, seeing how Unicode is integrating ever more icons under the
> name "emoji".

I think showing arbitrary images by displaying a special codepoint
will always be worse than just displaying images.  Especially so when
PU codepoints are used for those purposes.

Re: High-res Customize icons

[Stefan Monnier]

> We are talking about specific use cases, not in general.
[...]
> I think showing arbitrary images by displaying a special codepoint
> will always be worse than just displaying images.

The specific use cases that all-the-icons aims to cover is not "showing
arbitrary images".  It's mainly prettifying the modeline, using small
icons instead of text in the modeline to save space, and adding small
icons on each line in a list buffer like dired.  In these 3 cases,
I don't think using fonts is obviously more wrong than using images.


        Stefan

Re: High-res Customize icons

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: cpitclaudel@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 24 Apr 2020 11:13:35 -0400
> 
> The specific use cases that all-the-icons aims to cover is not "showing
> arbitrary images".  It's mainly prettifying the modeline, using small
> icons instead of text in the modeline to save space, and adding small
> icons on each line in a list buffer like dired.  In these 3 cases,
> I don't think using fonts is obviously more wrong than using images.

I tried to explain why I disagree.

Re: High-res Customize icons

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 23 Apr 2020 16:46:10 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>, ndame <ndame@protonmail.com>
> 
> Fonts are vectors graphics (well, these are), so you can scale them
> without them turning blocky/smudgy.  I think that's the most important
> reason for using fonts instead of images.

Don't SVG images share this nice feature?

Re: High-res Customize icons

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Fonts are vectors graphics (well, these are), so you can scale them
>> without them turning blocky/smudgy.  I think that's the most important
>> reason for using fonts instead of images.
>
> Don't SVG images share this nice feature?

They do indeed, but somebody else in the thread said that SVG images had
been considered for the icons, and that had been rejected, I think?
(Perhaps because not all Emacsen are built with SVG support?)

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

Re: High-res Customize icons

[Yuan Fu]

> (Perhaps because not all Emacsen are built with SVG support?)

Because Emacs doesn’t have good (enough) support for SVG images, I think. E.g., transparent background, scaling. 

Yuan

Re: High-res Customize icons

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 23 Apr 2020 16:11:18 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > Thinking about this a bit more, why did they choose to package the
> > icons up as ttf fonts instead of just including them as image files?
> > Is there any benefit to doing it that way?
> 
> I just realized that his will allow you to change the color of the
> icons.  Duh.  So that's a pretty nice idea, I guess.

Is it?  Why, can't you change the color of an image as well?

Re: High-res Customize icons

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> > I just realized that his will allow you to change the color of the
> > icons.  Duh.  So that's a pretty nice idea, I guess.
>
> Is it?  Why, can't you change the color of an image as well?

Well, it's arguably easier with a ttf font since it would use the face
color automatically...  But we should of course be able to ensure
icons can work just as well, and on balance you have convinced me that
the ttf fonts are an undesirable hack.

Best regards,
Stefan Kangas

Re: High-res Customize icons

[Stefan Kangas]

> icons can work just as well, and on balance you have convinced me that
   ^^^^^ should be "images"

Re: High-res Customize icons

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 23 Apr 2020 16:07:30 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> Thinking about this a bit more, why did they choose to package the
> icons up as ttf fonts instead of just including them as image files?

An excellent question, IMO.

Re: High-res Customize icons

[Clément Pit-Claudel]

On 23/04/2020 11.08, Eli Zaretskii wrote:
>> From: Stefan Kangas <stefan@marxist.se>
>> Date: Thu, 23 Apr 2020 16:07:30 +0200
>> Cc: Emacs developers <emacs-devel@gnu.org>
>>
>> Thinking about this a bit more, why did they choose to package the
>> icons up as ttf fonts instead of just including them as image files?
> 
> An excellent question, IMO.

I agree, but we need to solve two concrete issues with SVG scalable images before they are usable:

* Automatic scaling (changing the font size automatically resizes icon fonts, but not images)
* Adjusting the background color (currently the SVG renderer uses the background color of the default face, while icon fonts use the right background color)

Juri mentioned these issues in https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00414.html, and until we have a fix SVG isn't really usable as a replacement for icon fonts.

Clément.

Re: High-res Customize icons

[Stefan Kangas]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> I agree, but we need to solve two concrete issues with SVG scalable images before they are usable:
>
> * Automatic scaling (changing the font size automatically resizes icon fonts, but not images)

I seem to remember we discussed this a while back, but can't find it
now nor remember the conclusion.

> * Adjusting the background color (currently the SVG renderer uses the background color of the default face, while icon fonts use the right background color)
>
> Juri mentioned these issues in https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00414.html, and until we have a fix SVG isn't really usable as a replacement for icon fonts.

There's also the issue of scaling the svg images using librsvg, which
can only scale using cairo or with a deprecated method.  If I read the
above thread correctly, the suggestions are:

1. Find a way to use librsvg + cairo to scale images in a toolkit
independent way.
2. Lars suggested to modify the XML (the svg file).
3. Change to a different svg library.

I'm not sure which of these would be the most practical.

Here's a relevant Stack Overflow question:
https://stackoverflow.com/questions/7540901/scaling-vector-images-through-librsvg

Best regards,
Stefan Kangas

Re: High-res Customize icons

[Clément Pit-Claudel]

On 23/04/2020 12.34, Stefan Kangas wrote:
> Clément Pit-Claudel <cpitclaudel@gmail.com> writes:
> 
>> I agree, but we need to solve two concrete issues with SVG scalable images before they are usable:
>>
>> * Automatic scaling (changing the font size automatically resizes icon fonts, but not images)
> 
> I seem to remember we discussed this a while back, but can't find it
> now nor remember the conclusion.

Maybe this: https://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00689.html and especially this: https://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00741.html ?

Clément.

Re: High-res Customize icons

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, ndame@protonmail.com
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 23 Apr 2020 11:49:04 -0400
> 
> I agree, but we need to solve two concrete issues with SVG scalable images before they are usable:
> 
> * Automatic scaling (changing the font size automatically resizes icon fonts, but not images)
> * Adjusting the background color (currently the SVG renderer uses the background color of the default face, while icon fonts use the right background color)

So let's fix them, that doesn't sound too difficult.

I really don't like using fonts for this purpose.  Fonts are not there
to display icons, they are to display characters, and the Emacs
machinery that uses fonts is designed for that purpose.  Building
basic features on such tricks is IME a bad investment.

Re: High-res Customize icons

[Clément Pit-Claudel]

On 23/04/2020 15.12, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org, ndame@protonmail.com
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 23 Apr 2020 11:49:04 -0400
>>
>> I agree, but we need to solve two concrete issues with SVG scalable images before they are usable:
>>
>> * Automatic scaling (changing the font size automatically resizes icon fonts, but not images)
>> * Adjusting the background color (currently the SVG renderer uses the background color of the default face, while icon fonts use the right background color)
> 
> So let's fix them, that doesn't sound too difficult.

That's great to hear; it's often hard to know what's easy and what isn't ^^
Are these bugs tracked somewhere?  If not, here's a simple repro, which at least should provide a consistent recipe to start fixing the problem(s):

(with-current-buffer (get-buffer-create "*svg bugs*")
  (erase-buffer)
  (require 'face-remap)
  (setq text-scale-mode-amount 10)
  (text-scale-mode)
  (let ((svg (svg-create 16 16)))
    (svg-ellipse svg 8 8 4 4)
    (insert "Text: ")
    (print (svg-image svg :ascent 100))
    (insert-image (svg-image svg :ascent 100))
    (insert-image (svg-image svg :scale 5.0 :ascent 'center :foreground "red" :background "darkgreen"))
    (put-text-property (point-min) (point-max) 'face '(:foreground "orange" :background "purple")))
  (pop-to-buffer (current-buffer)))

The issues:

1. Manually scaling an image, as is done for the second image, doesn't re-render the svg: is scales the bitmap-rendered version of it, causing blurriness
2. The SVG images don't inherit the background of the current face; instead, they inherit the background of the default face.
3. The SVG images don't inherit the foreground of the current face; instead, they use a black foreground.
4. The :foreground keyword has no effect on svg images.
5. The images are not scaled with the text: changing text-scale-mode-amount doesn't change the size of the images.

For 1, 2, 3, and 4, the expected behavior is easy to define:
- For 1, the image should be scaled before being rasterized. 
- For 2 and 3, the image should inherit the characteristics of the current face, and be re-rendered if that face changes.
- For 3, the :foreground property should apply

For 5, it's a bit trickier.  One option would be to accept a float-valued :height specification and understand this as a multiple of the current font size?

The workaround for 2 is not too bad (add an explicit :background); for the other issues, it's quite bit trickier (for 1 it can be enough to set the size in the SVG, but that only works easily for SVGs created within emacs).

Sorry if this is redundant or if I missed something obvious,
Clément.

Re: High-res Customize icons

[Eli Zaretskii]

> Cc: stefan@marxist.se, emacs-devel@gnu.org, ndame@protonmail.com
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 24 Apr 2020 22:55:13 -0400
> 
> >> * Adjusting the background color (currently the SVG renderer uses the background color of the default face, while icon fonts use the right background color)
> > 
> > So let's fix them, that doesn't sound too difficult.
> 
> That's great to hear; it's often hard to know what's easy and what isn't ^^
> Are these bugs tracked somewhere?  If not, here's a simple repro, which at least should provide a consistent recipe to start fixing the problem(s):

Thanks, but this should go to the bug tracker, not to this list.  Then
it will be tracked, and eventually hopefully fixed.

Re: High-res Customize icons

[Clément Pit-Claudel]

On 25/04/2020 03.03, Eli Zaretskii wrote:
>> Cc: stefan@marxist.se, emacs-devel@gnu.org, ndame@protonmail.com
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Fri, 24 Apr 2020 22:55:13 -0400
>>
>>>> * Adjusting the background color (currently the SVG renderer uses the background color of the default face, while icon fonts use the right background color)
>>>
>>> So let's fix them, that doesn't sound too difficult.
>>
>> That's great to hear; it's often hard to know what's easy and what isn't ^^
>> Are these bugs tracked somewhere?  If not, here's a simple repro, which at least should provide a consistent recipe to start fixing the problem(s):
> 
> Thanks, but this should go to the bug tracker, not to this list.  Then
> it will be tracked, and eventually hopefully fixed.

Of course. I just wanted to make sure not to create a duplicate report.  Filed as #40845.

Re: High-res Customize icons

[Stefan Kangas]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> Of course. I just wanted to make sure not to create a duplicate report.  Filed as #40845.

Speaking as a person who has spent some time triaging and closing
bugs, may I suggest you file separate bugs for the different issues?
It seems to me that (1) [blurry scaling] and (5) [scaling together
with text] are separate issues, while (2), (3) and (4)
[foreground/background inheritance] are more related and maybe best
handled together.

Best regards,
Stefan Kangas

Re: High-res Customize icons

[Eli Zaretskii]

> Date: Thu, 23 Apr 2020 07:14:48 +0000
> From: ndame <ndame@protonmail.com>
> 
> > It should be straightforward to take a free font family, strip all
> > other glyphs, and modify the remaining symbols to make them fit.
> 
> Actually, there is an emacs package already which collects fonts
> with free license to provide icons:
> 
> https://github.com/domtronn/all-the-icons.el
> 
> Check out the screenshot, e.g. the mode line at the bottom which looks quite nice:
> 
> https://raw.githubusercontent.com/domtronn/all-the-icons.el/master/logo.png
> 
> It would be nice if emacs shipped with these fonts and actually used the icons at various
> places like on the screenshot.

Sorry, I cannot say I like this.  AFAIU, it uses Private Use Area
(PUA) codepoints to produce the icons with a specially-prepared font.
But the fonts it provides declare support for portions of Unicode
where they have glyphs for only one or a small number of characters.
So if this font is installed and available to the Emacs font-selection
routines, it will at best make the search for a font slower, and at
worst might cause some characters be displayed as boxes with hex
codes, although some other font on the system could have displayed
that character.

I'm especially alarmed to see advice like this:

  . If you don't see the font family in question in the list of
    fontspecs (i.e. [-*-file-icons-...]) below the range, or some
    other fontspecs in front of the one in question, you will have to
    add the families back to the fontset (scroll to the top to see
    which one is in effect), or arrange the fontspec order. For
    example:

     (set-fontset-font t 'unicode (font-spec :family "all-the-icons") nil 'append)

This in effect tells Emacs that the font in question covers the entire
Unicode code-space, which is definitely far from the truth.

From my POV, this has trouble written all over it.  We have enough
font-related issues reported on the bug tracker, and zero people who
know this area of Emacs well enough to respond to those bugs
efficiently.  Using tricks like the above will make a difficult
situation much more so, and for no good reason.

Re: High-res Customize icons

[ndame]

> and at worst might cause some characters be displayed as boxes with hex
> codes, although some other font on the system could have displayed
> that character.

If this custom font is only used for displaying icons then why would
it show characters displayed as boxes?

The font could even have a custom name like 'internal font, don't use it'
to warn users not trying to use it as a regular font.

Re: High-res Customize icons

[Eli Zaretskii]

> Date: Fri, 24 Apr 2020 15:11:50 +0000
> From: ndame <ndame@protonmail.com>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> > and at worst might cause some characters be displayed as boxes with hex
> > codes, although some other font on the system could have displayed
> > that character.
> 
> If this custom font is only used for displaying icons then why would
> it show characters displayed as boxes?

Emacs doesn't have facilities to use a font "only for something".

> The font could even have a custom name like 'internal font, don't use it'
> to warn users not trying to use it as a regular font.

We don't have facilities to do this, AFAIK.  Font selection uses the
script of the character and the font coverage.  It isn't a user =level
issue: once the font is known to the system and/or to the functions
that enumerate existing fonts, it will be considered whenever Emacs
needs a font for some character.

Re: High-res Customize icons

[Stefan Monnier]

>> If this custom font is only used for displaying icons then why would
>> it show characters displayed as boxes?
> Emacs doesn't have facilities to use a font "only for something".

We do have some limited control via the faces (e.g. the family/foundry
part of the face).  IIUC the `charset` property might also play a role.

It doesn't address the fact that the fonts are either "available" or
not, for the whole of Emacs.


        Stefan

Re: High-res Customize icons

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: ndame <ndame@protonmail.com>,  emacs-devel@gnu.org
> Date: Fri, 24 Apr 2020 12:07:39 -0400
> 
> >> If this custom font is only used for displaying icons then why would
> >> it show characters displayed as boxes?
> > Emacs doesn't have facilities to use a font "only for something".
> 
> We do have some limited control via the faces (e.g. the family/foundry
> part of the face).  IIUC the `charset` property might also play a role.

Both of these are not really good tools, even on X, where XLFD is
well-entrenched.  If we want to have special-purpose fonts, we need
more reliable features, IMO.

Re: High-res Customize icons

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > We don't have facilities to do this, AFAIK.  Font selection uses the
  > script of the character and the font coverage.  It isn't a user =level
  > issue: once the font is known to the system and/or to the functions
  > that enumerate existing fonts, it will be considered whenever Emacs
  > needs a font for some character.

It would not be hard to mark a font to be ignored
in ordinary font selection -- and do something special
to choose that font for an icon.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: High-res Customize icons

[Robert Pluim]

>>>>> On Fri, 24 Apr 2020 23:38:21 -0400, Richard Stallman <rms@gnu.org> said:

    Richard> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
    Richard> [[[ whether defending the US Constitution against all enemies,     ]]]
    Richard> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    >> We don't have facilities to do this, AFAIK.  Font selection uses the
    >> script of the character and the font coverage.  It isn't a user =level
    >> issue: once the font is known to the system and/or to the functions
    >> that enumerate existing fonts, it will be considered whenever Emacs
    >> needs a font for some character.

    Richard> It would not be hard to mark a font to be ignored
    Richard> in ordinary font selection -- and do something special
    Richard> to choose that font for an icon.

The first half of that already exists:

    face-ignored-fonts is a variable defined in `C source code'.
    Its value is nil

      Probably introduced at or before Emacs version 21.1.

    Documentation:
    List of ignored fonts.
    Each element is a regular expression that matches names of fonts to
    ignore.

Re: High-res Customize icons

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Tue, 28 Apr 2020 15:55:33 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, ndame@protonmail.com, emacs-devel@gnu.org
> 
>     Richard> It would not be hard to mark a font to be ignored
>     Richard> in ordinary font selection -- and do something special
>     Richard> to choose that font for an icon.
> 
> The first half of that already exists:
> 
>     face-ignored-fonts is a variable defined in `C source code'.
>     Its value is nil

This variable is not for the kind of tricks we were discussing here.
The variable exists to allow users tell Emacs not to use specific
fonts for _anything_, on account of them being ugly or inappropriate,
or maybe because they crash Emacs.  The fonts mentioned there will not
be selected for any codepoint, AFAIU.

Re: High-res Customize icons

[Robert Pluim]

>>>>> On Tue, 28 Apr 2020 17:38:34 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Tue, 28 Apr 2020 15:55:33 +0200
    >> Cc: Eli Zaretskii <eliz@gnu.org>, ndame@protonmail.com, emacs-devel@gnu.org
    >> 
    Richard> It would not be hard to mark a font to be ignored
    Richard> in ordinary font selection -- and do something special
    Richard> to choose that font for an icon.
    >> 
    >> The first half of that already exists:
    >> 
    >> face-ignored-fonts is a variable defined in `C source code'.
    >> Its value is nil

    Eli> This variable is not for the kind of tricks we were discussing here.
    Eli> The variable exists to allow users tell Emacs not to use specific
    Eli> fonts for _anything_, on account of them being ugly or inappropriate,
    Eli> or maybe because they crash Emacs.  The fonts mentioned there will not
    Eli> be selected for any codepoint, AFAIU.

Yes, but what I meant is that the mechanism exists. We could add a
non-visible analogue to exclude the hypothetical 'special' font
(although I think I too would prefer to use images).

Robert

Re: High-res Customize icons

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Wed, 29 Apr 2020 14:30:29 +0200
> Cc: ndame@protonmail.com, rms@gnu.org, emacs-devel@gnu.org
> 
>     >> face-ignored-fonts is a variable defined in `C source code'.
>     >> Its value is nil
> 
>     Eli> This variable is not for the kind of tricks we were discussing here.
>     Eli> The variable exists to allow users tell Emacs not to use specific
>     Eli> fonts for _anything_, on account of them being ugly or inappropriate,
>     Eli> or maybe because they crash Emacs.  The fonts mentioned there will not
>     Eli> be selected for any codepoint, AFAIU.
> 
> Yes, but what I meant is that the mechanism exists.

Mechanism for absolute exclusion does exist.  But what is sought here
is a mechanism for _selective_ exclusion (since we are supposed to use
special codepoints of characters to trigger display of those icons),
and such a mechanism needs to be developed.

Re: High-res Customize icons

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > But the fonts it provides declare support for portions of Unicode
  > where they have glyphs for only one or a small number of characters.
  > So if this font is installed and available to the Emacs font-selection
  > routines, it will at best make the search for a font slower, and at
  > worst might cause some characters be displayed as boxes with hex
  > codes, although some other font on the system could have displayed
  > that character.

These fonts don't HAVE to be selected via the usual Emacs font selection
mechanism.  It should be easy enough to force use of some specific font
for them.

We don't have to specify display of these font glyphs by putting a
funny character into a buffer or string with a face property.
Doing it that way is one possible Lisp interface to those fonts.

But if some other Lisp interface is more convenient, it should not be
too hard.  And it could override the usual system for font selection.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: High-res Customize icons

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: ndame@protonmail.com, emacs-devel@gnu.org
> Date: Fri, 24 Apr 2020 23:34:10 -0400
> 
>   > But the fonts it provides declare support for portions of Unicode
>   > where they have glyphs for only one or a small number of characters.
>   > So if this font is installed and available to the Emacs font-selection
>   > routines, it will at best make the search for a font slower, and at
>   > worst might cause some characters be displayed as boxes with hex
>   > codes, although some other font on the system could have displayed
>   > that character.
> 
> These fonts don't HAVE to be selected via the usual Emacs font selection
> mechanism.  It should be easy enough to force use of some specific font
> for them.

"Easy enough" is IME too optimistic, to say the least.  The Emacs
font-selection machinery is very complex and notoriously
under-documented.  It manipulates 3 similar, but different object
types, whose reference to the reality and the role in eventually
selecting a suitable font is at least in my eyes unclear and
confusing.  We don't have active developers on board who know that
code well enough to make deep changes in it without breaking
something.  So I doubt if "easy" is anywhere near the truth.

That said, we currently have no way known to me to special-case any
fonts for selection or non-selection limited to some special use
cases.  (Of course, no one in this discussion has suggested how to
define those special cases, either, so we are largely having an
academic argument here.  What else is new.)  We can only say "don't
select this font for anything", which is both inappropriate for the
purpose being discussed, and is not what's needed.

So what you propose must be coded first, and in C.  If someone
presents the code to do that and the spec for Lisp-level feature that
would expose such capabilities, we could discuss that, regardless of
whether this should or shouldn't be used for the purpose of making the
Emacs UI more "shiny".

But that's not what is being proposed here.  What is being proposed is
to use special fonts, that Emacs will provide as part of its tarball,
and which will use special PUA codepoints to display some icons.  This
will (a) make other programs be aware of these fonts and try using
them, (b) get in the way of unrelated uses of those same PUA
codepoints, and (c) make Emacs's search for a suitable font slower and
more expensive.  So I think we shouldn't take this path.  We should
instead use real images, which Emacs already knows how to display.

> We don't have to specify display of these font glyphs by putting a
> funny character into a buffer or string with a face property.
> Doing it that way is one possible Lisp interface to those fonts.

That's the only interface that was proposed.  What other interfaces do
you have in mind?  Anything concrete in particular?

Please keep in mind the higher-level context of this discussion: we
are being told that Emacs presents an archaic UI while ready-to-use
solutions exist out there that solve this issue nicely and easily.  We
are being pointed to this use of fonts with PUA codepoints as one of
those solutions, and are being asked why not just take that package
and import it into core for immediate improvement of the UI.  Let's
please keep this context in mind when considering the opinions I
expressed on these proposals.  I wasn't just talking about some
abstract suggestion for using fonts for some abstract purpose in some
unspecified part of the Emacs display.  Frankly, I have little
interest in such abstract discussions.