* High-res Customize icons @ 2020-04-21 19:47 Yuan Fu 2020-04-22 2:23 ` Eli Zaretskii 0 siblings, 1 reply; 88+ messages in thread From: Yuan Fu @ 2020-04-21 19:47 UTC (permalink / raw) To: Emacs developers 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-21 19:47 High-res Customize icons Yuan Fu @ 2020-04-22 2:23 ` Eli Zaretskii 2020-04-22 2:37 ` Clément Pit-Claudel 0 siblings, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-22 2:23 UTC (permalink / raw) To: Yuan Fu; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 2:23 ` Eli Zaretskii @ 2020-04-22 2:37 ` Clément Pit-Claudel 2020-04-22 5:47 ` chad 0 siblings, 1 reply; 88+ messages in thread From: Clément Pit-Claudel @ 2020-04-22 2:37 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 2:37 ` Clément Pit-Claudel @ 2020-04-22 5:47 ` chad 2020-04-22 12:24 ` Yuan Fu 2020-04-22 13:35 ` Eli Zaretskii 0 siblings, 2 replies; 88+ messages in thread From: chad @ 2020-04-22 5:47 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: EMACS development team [-- 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 --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 5:47 ` chad @ 2020-04-22 12:24 ` Yuan Fu 2020-04-22 12:41 ` Yuri Khan 2020-04-22 13:35 ` Eli Zaretskii 1 sibling, 1 reply; 88+ messages in thread From: Yuan Fu @ 2020-04-22 12:24 UTC (permalink / raw) To: chad; +Cc: Clément Pit-Claudel, EMACS development team [-- 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 --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 12:24 ` Yuan Fu @ 2020-04-22 12:41 ` Yuri Khan 2020-04-22 13:54 ` Yuan Fu 0 siblings, 1 reply; 88+ messages in thread From: Yuri Khan @ 2020-04-22 12:41 UTC (permalink / raw) To: Yuan Fu; +Cc: chad, Clément Pit-Claudel, EMACS development team [-- 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 --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 12:41 ` Yuri Khan @ 2020-04-22 13:54 ` Yuan Fu 2020-04-22 21:12 ` Juri Linkov 0 siblings, 1 reply; 88+ messages in thread From: Yuan Fu @ 2020-04-22 13:54 UTC (permalink / raw) To: Yuri Khan Cc: chad, Juri Linkov, Clément Pit-Claudel, EMACS development team [-- 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 --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 13:54 ` Yuan Fu @ 2020-04-22 21:12 ` Juri Linkov 2020-04-22 22:20 ` Yuan Fu 2020-04-23 4:11 ` Werner LEMBERG 0 siblings, 2 replies; 88+ messages in thread From: Juri Linkov @ 2020-04-22 21:12 UTC (permalink / raw) To: Yuan Fu; +Cc: chad, EMACS development team, Clément Pit-Claudel, Yuri Khan > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 21:12 ` Juri Linkov @ 2020-04-22 22:20 ` Yuan Fu 2020-04-23 4:11 ` Werner LEMBERG 1 sibling, 0 replies; 88+ messages in thread From: Yuan Fu @ 2020-04-22 22:20 UTC (permalink / raw) To: Juri Linkov Cc: chad, EMACS development team, Clément Pit-Claudel, Yuri Khan [-- 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 --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 21:12 ` Juri Linkov 2020-04-22 22:20 ` Yuan Fu @ 2020-04-23 4:11 ` Werner LEMBERG 2020-04-23 14:52 ` Eli Zaretskii 1 sibling, 1 reply; 88+ messages in thread From: Werner LEMBERG @ 2020-04-23 4:11 UTC (permalink / raw) To: juri; +Cc: casouri, yuri.v.khan, cpitclaudel, yandros, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 4:11 ` Werner LEMBERG @ 2020-04-23 14:52 ` Eli Zaretskii 2020-04-23 15:07 ` Clément Pit-Claudel 2020-04-23 17:49 ` Werner LEMBERG 0 siblings, 2 replies; 88+ messages in thread From: Eli Zaretskii @ 2020-04-23 14:52 UTC (permalink / raw) To: Werner LEMBERG Cc: juri, casouri, cpitclaudel, emacs-devel, yandros, yuri.v.khan > 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? ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 14:52 ` Eli Zaretskii @ 2020-04-23 15:07 ` Clément Pit-Claudel 2020-04-23 17:49 ` Werner LEMBERG 1 sibling, 0 replies; 88+ messages in thread From: Clément Pit-Claudel @ 2020-04-23 15:07 UTC (permalink / raw) To: Eli Zaretskii, Werner LEMBERG Cc: casouri, yuri.v.khan, emacs-devel, yandros, juri 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 14:52 ` Eli Zaretskii 2020-04-23 15:07 ` Clément Pit-Claudel @ 2020-04-23 17:49 ` Werner LEMBERG 2020-04-23 19:27 ` Eli Zaretskii 1 sibling, 1 reply; 88+ messages in thread From: Werner LEMBERG @ 2020-04-23 17:49 UTC (permalink / raw) To: eliz; +Cc: juri, casouri, cpitclaudel, emacs-devel, yandros, yuri.v.khan >> 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 17:49 ` Werner LEMBERG @ 2020-04-23 19:27 ` Eli Zaretskii 2020-04-23 19:35 ` Yuan Fu ` (2 more replies) 0 siblings, 3 replies; 88+ messages in thread From: Eli Zaretskii @ 2020-04-23 19:27 UTC (permalink / raw) To: Werner LEMBERG Cc: juri, casouri, cpitclaudel, emacs-devel, yandros, yuri.v.khan > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 19:27 ` Eli Zaretskii @ 2020-04-23 19:35 ` Yuan Fu 2020-04-23 19:40 ` Eli Zaretskii 2020-04-23 23:23 ` chad 2020-04-25 3:30 ` Richard Stallman 2 siblings, 1 reply; 88+ messages in thread From: Yuan Fu @ 2020-04-23 19:35 UTC (permalink / raw) To: Eli Zaretskii Cc: Juri Linkov, Clément Pit-Claudel, emacs-devel, yandros, Yuri Khan [-- 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 --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 19:35 ` Yuan Fu @ 2020-04-23 19:40 ` Eli Zaretskii 2020-04-23 19:59 ` Yuan Fu 0 siblings, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-23 19:40 UTC (permalink / raw) To: Yuan Fu; +Cc: juri, cpitclaudel, emacs-devel, yandros, yuri.v.khan > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 19:40 ` Eli Zaretskii @ 2020-04-23 19:59 ` Yuan Fu 2020-04-23 23:02 ` chad 2020-04-24 6:30 ` Eli Zaretskii 0 siblings, 2 replies; 88+ messages in thread From: Yuan Fu @ 2020-04-23 19:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Juri Linkov, cpitclaudel, emacs-devel, yandros, yuri.v.khan > 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 19:59 ` Yuan Fu @ 2020-04-23 23:02 ` chad 2020-04-24 6:30 ` Eli Zaretskii 1 sibling, 0 replies; 88+ messages in thread From: chad @ 2020-04-23 23:02 UTC (permalink / raw) To: Yuan Fu Cc: Juri Linkov, Clément Pit-Claudel, EMACS development team, Eli Zaretskii, Yuri Khan [-- 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 --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 19:59 ` Yuan Fu 2020-04-23 23:02 ` chad @ 2020-04-24 6:30 ` Eli Zaretskii 2020-04-24 11:00 ` Dmitry Gutov 1 sibling, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-24 6:30 UTC (permalink / raw) To: Yuan Fu; +Cc: juri, cpitclaudel, emacs-devel, yandros, yuri.v.khan > 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? ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-24 6:30 ` Eli Zaretskii @ 2020-04-24 11:00 ` Dmitry Gutov 0 siblings, 0 replies; 88+ messages in thread From: Dmitry Gutov @ 2020-04-24 11:00 UTC (permalink / raw) To: Eli Zaretskii, Yuan Fu Cc: cpitclaudel, emacs-devel, yuri.v.khan, yandros, juri 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 19:27 ` Eli Zaretskii 2020-04-23 19:35 ` Yuan Fu @ 2020-04-23 23:23 ` chad 2020-04-24 7:18 ` Eli Zaretskii 2020-04-25 3:30 ` Richard Stallman 2 siblings, 1 reply; 88+ messages in thread From: chad @ 2020-04-23 23:23 UTC (permalink / raw) To: Eli Zaretskii Cc: Juri Linkov, Yuan Fu, Clément Pit-Claudel, EMACS development team, Yuri Khan [-- 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 --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 23:23 ` chad @ 2020-04-24 7:18 ` Eli Zaretskii 0 siblings, 0 replies; 88+ messages in thread From: Eli Zaretskii @ 2020-04-24 7:18 UTC (permalink / raw) To: chad; +Cc: juri, casouri, cpitclaudel, emacs-devel, yuri.v.khan > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 19:27 ` Eli Zaretskii 2020-04-23 19:35 ` Yuan Fu 2020-04-23 23:23 ` chad @ 2020-04-25 3:30 ` Richard Stallman 2020-04-25 7:02 ` Eli Zaretskii 2 siblings, 1 reply; 88+ messages in thread From: Richard Stallman @ 2020-04-25 3:30 UTC (permalink / raw) To: Eli Zaretskii Cc: casouri, yuri.v.khan, cpitclaudel, emacs-devel, yandros, juri [[[ 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) ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-25 3:30 ` Richard Stallman @ 2020-04-25 7:02 ` Eli Zaretskii 2020-04-25 12:37 ` Clément Pit-Claudel 0 siblings, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-25 7:02 UTC (permalink / raw) To: rms; +Cc: casouri, yuri.v.khan, cpitclaudel, emacs-devel, yandros, juri > 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? ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-25 7:02 ` Eli Zaretskii @ 2020-04-25 12:37 ` Clément Pit-Claudel 2020-04-25 13:56 ` Eli Zaretskii 0 siblings, 1 reply; 88+ messages in thread From: Clément Pit-Claudel @ 2020-04-25 12:37 UTC (permalink / raw) To: Eli Zaretskii, rms; +Cc: juri, casouri, yuri.v.khan, yandros, emacs-devel 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-25 12:37 ` Clément Pit-Claudel @ 2020-04-25 13:56 ` Eli Zaretskii 0 siblings, 0 replies; 88+ messages in thread From: Eli Zaretskii @ 2020-04-25 13:56 UTC (permalink / raw) To: Clément Pit-Claudel Cc: casouri, rms, yuri.v.khan, emacs-devel, yandros, juri > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 5:47 ` chad 2020-04-22 12:24 ` Yuan Fu @ 2020-04-22 13:35 ` Eli Zaretskii 2020-04-22 17:09 ` chad 1 sibling, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-22 13:35 UTC (permalink / raw) To: chad; +Cc: cpitclaudel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 13:35 ` Eli Zaretskii @ 2020-04-22 17:09 ` chad 2020-04-22 17:36 ` Eli Zaretskii 0 siblings, 1 reply; 88+ messages in thread From: chad @ 2020-04-22 17:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Clément Pit-Claudel, EMACS development team [-- 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 --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 17:09 ` chad @ 2020-04-22 17:36 ` Eli Zaretskii 2020-04-22 18:28 ` chad 0 siblings, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-22 17:36 UTC (permalink / raw) To: chad; +Cc: cpitclaudel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 17:36 ` Eli Zaretskii @ 2020-04-22 18:28 ` chad 2020-04-22 18:38 ` Eli Zaretskii 0 siblings, 1 reply; 88+ messages in thread From: chad @ 2020-04-22 18:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Clément Pit-Claudel, EMACS development team [-- 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 --] ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 18:28 ` chad @ 2020-04-22 18:38 ` Eli Zaretskii 2020-04-22 19:19 ` Yuan Fu 0 siblings, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-22 18:38 UTC (permalink / raw) To: chad; +Cc: cpitclaudel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 18:38 ` Eli Zaretskii @ 2020-04-22 19:19 ` Yuan Fu 2020-04-22 19:28 ` Eli Zaretskii 0 siblings, 1 reply; 88+ messages in thread From: Yuan Fu @ 2020-04-22 19:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: chad, Clément Pit-Claudel, emacs-devel > 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 19:19 ` Yuan Fu @ 2020-04-22 19:28 ` Eli Zaretskii 2020-04-22 20:38 ` Yuan Fu 0 siblings, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-22 19:28 UTC (permalink / raw) To: Yuan Fu; +Cc: yandros, cpitclaudel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 19:28 ` Eli Zaretskii @ 2020-04-22 20:38 ` Yuan Fu 2020-05-01 13:46 ` Eli Zaretskii 0 siblings, 1 reply; 88+ messages in thread From: Yuan Fu @ 2020-04-22 20:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: yandros, cpitclaudel, emacs-devel [-- 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 --] ^ permalink raw reply related [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-22 20:38 ` Yuan Fu @ 2020-05-01 13:46 ` Eli Zaretskii 2020-10-22 15:33 ` Yuan Fu 2020-10-23 16:39 ` Yuan Fu 0 siblings, 2 replies; 88+ messages in thread From: Eli Zaretskii @ 2020-05-01 13:46 UTC (permalink / raw) To: Yuan Fu; +Cc: yandros, cpitclaudel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-05-01 13:46 ` Eli Zaretskii @ 2020-10-22 15:33 ` Yuan Fu 2020-10-23 16:39 ` Yuan Fu 1 sibling, 0 replies; 88+ messages in thread From: Yuan Fu @ 2020-10-22 15:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: chad, Clément Pit-Claudel, emacs-devel > 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-05-01 13:46 ` Eli Zaretskii 2020-10-22 15:33 ` Yuan Fu @ 2020-10-23 16:39 ` Yuan Fu 2020-10-23 18:08 ` Eli Zaretskii 1 sibling, 1 reply; 88+ messages in thread From: Yuan Fu @ 2020-10-23 16:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: chad, cpitclaudel, emacs-devel > 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-10-23 16:39 ` Yuan Fu @ 2020-10-23 18:08 ` Eli Zaretskii 2020-10-27 19:17 ` Yuan Fu 0 siblings, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-10-23 18:08 UTC (permalink / raw) To: Yuan Fu; +Cc: yandros, cpitclaudel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-10-23 18:08 ` Eli Zaretskii @ 2020-10-27 19:17 ` Yuan Fu 2020-10-27 19:27 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 88+ messages in thread From: Yuan Fu @ 2020-10-27 19:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: chad, Clément Pit-Claudel, emacs-devel > > 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-10-27 19:17 ` Yuan Fu @ 2020-10-27 19:27 ` Eli Zaretskii 2020-10-27 22:26 ` Alan Third 2020-10-28 1:22 ` YAMAMOTO Mitsuharu 2 siblings, 0 replies; 88+ messages in thread From: Eli Zaretskii @ 2020-10-27 19:27 UTC (permalink / raw) To: Yuan Fu, Alan Third; +Cc: yandros, cpitclaudel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-10-27 19:17 ` Yuan Fu 2020-10-27 19:27 ` Eli Zaretskii @ 2020-10-27 22:26 ` Alan Third 2020-10-27 23:09 ` Yuan Fu 2020-10-28 1:22 ` YAMAMOTO Mitsuharu 2 siblings, 1 reply; 88+ messages in thread From: Alan Third @ 2020-10-27 22:26 UTC (permalink / raw) To: Yuan Fu; +Cc: Eli Zaretskii, Clément Pit-Claudel, chad, emacs-devel 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-10-27 22:26 ` Alan Third @ 2020-10-27 23:09 ` Yuan Fu 2020-10-28 0:05 ` Alan Third 0 siblings, 1 reply; 88+ messages in thread From: Yuan Fu @ 2020-10-27 23:09 UTC (permalink / raw) To: Alan Third; +Cc: Eli Zaretskii, Clément Pit-Claudel, chad, emacs-devel > 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-10-27 23:09 ` Yuan Fu @ 2020-10-28 0:05 ` Alan Third 0 siblings, 0 replies; 88+ messages in thread From: Alan Third @ 2020-10-28 0:05 UTC (permalink / raw) To: Yuan Fu; +Cc: Eli Zaretskii, Clément Pit-Claudel, chad, emacs-devel [-- 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 ^ permalink raw reply related [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-10-27 19:17 ` Yuan Fu 2020-10-27 19:27 ` Eli Zaretskii 2020-10-27 22:26 ` Alan Third @ 2020-10-28 1:22 ` YAMAMOTO Mitsuharu 2020-10-29 5:31 ` Yuan Fu 2 siblings, 1 reply; 88+ messages in thread From: YAMAMOTO Mitsuharu @ 2020-10-28 1:22 UTC (permalink / raw) To: Yuan Fu; +Cc: Eli Zaretskii, Clément Pit-Claudel, chad, emacs-devel 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-10-28 1:22 ` YAMAMOTO Mitsuharu @ 2020-10-29 5:31 ` Yuan Fu 0 siblings, 0 replies; 88+ messages in thread From: Yuan Fu @ 2020-10-29 5:31 UTC (permalink / raw) To: YAMAMOTO Mitsuharu Cc: Eli Zaretskii, Clément Pit-Claudel, chad, emacs-devel > > 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons
@ 2020-04-23 7:14 ndame
2020-04-23 7:25 ` ndame
` (2 more replies)
0 siblings, 3 replies; 88+ messages in thread
From: ndame @ 2020-04-23 7:14 UTC (permalink / raw)
To: Emacs developers
[-- 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 --]
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 7:14 ndame @ 2020-04-23 7:25 ` ndame 2020-04-23 10:06 ` Stefan Kangas 2020-04-24 12:05 ` Eli Zaretskii 2 siblings, 0 replies; 88+ messages in thread From: ndame @ 2020-04-23 7:25 UTC (permalink / raw) To: Emacs developers > > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 7:14 ndame 2020-04-23 7:25 ` ndame @ 2020-04-23 10:06 ` Stefan Kangas 2020-04-23 14:07 ` Stefan Kangas 2020-04-24 12:05 ` Eli Zaretskii 2 siblings, 1 reply; 88+ messages in thread From: Stefan Kangas @ 2020-04-23 10:06 UTC (permalink / raw) To: ndame; +Cc: Emacs developers 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 10:06 ` Stefan Kangas @ 2020-04-23 14:07 ` Stefan Kangas 2020-04-23 14:11 ` Stefan Kangas 2020-04-23 15:08 ` Eli Zaretskii 0 siblings, 2 replies; 88+ messages in thread From: Stefan Kangas @ 2020-04-23 14:07 UTC (permalink / raw) To: ndame; +Cc: Emacs developers 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 14:07 ` Stefan Kangas @ 2020-04-23 14:11 ` Stefan Kangas 2020-04-23 14:39 ` Clément Pit-Claudel ` (2 more replies) 2020-04-23 15:08 ` Eli Zaretskii 1 sibling, 3 replies; 88+ messages in thread From: Stefan Kangas @ 2020-04-23 14:11 UTC (permalink / raw) To: ndame; +Cc: Emacs developers 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 14:11 ` Stefan Kangas @ 2020-04-23 14:39 ` Clément Pit-Claudel 2020-04-23 14:46 ` Lars Ingebrigtsen 2020-04-23 15:09 ` Eli Zaretskii 2 siblings, 0 replies; 88+ messages in thread From: Clément Pit-Claudel @ 2020-04-23 14:39 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 14:11 ` Stefan Kangas 2020-04-23 14:39 ` Clément Pit-Claudel @ 2020-04-23 14:46 ` Lars Ingebrigtsen 2020-04-23 15:00 ` Clément Pit-Claudel 2020-04-23 15:15 ` Eli Zaretskii 2020-04-23 15:09 ` Eli Zaretskii 2 siblings, 2 replies; 88+ messages in thread From: Lars Ingebrigtsen @ 2020-04-23 14:46 UTC (permalink / raw) To: Stefan Kangas; +Cc: Emacs developers, ndame 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 14:46 ` Lars Ingebrigtsen @ 2020-04-23 15:00 ` Clément Pit-Claudel 2020-04-23 15:44 ` Stefan Monnier 2020-04-23 15:15 ` Eli Zaretskii 1 sibling, 1 reply; 88+ messages in thread From: Clément Pit-Claudel @ 2020-04-23 15:00 UTC (permalink / raw) To: emacs-devel 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) ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 15:00 ` Clément Pit-Claudel @ 2020-04-23 15:44 ` Stefan Monnier 2020-04-23 19:14 ` Eli Zaretskii 0 siblings, 1 reply; 88+ messages in thread From: Stefan Monnier @ 2020-04-23 15:44 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 15:44 ` Stefan Monnier @ 2020-04-23 19:14 ` Eli Zaretskii 2020-04-23 20:33 ` Stefan Monnier 0 siblings, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-23 19:14 UTC (permalink / raw) To: Stefan Monnier; +Cc: cpitclaudel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 19:14 ` Eli Zaretskii @ 2020-04-23 20:33 ` Stefan Monnier 2020-04-24 6:51 ` Eli Zaretskii 0 siblings, 1 reply; 88+ messages in thread From: Stefan Monnier @ 2020-04-23 20:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cpitclaudel, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 20:33 ` Stefan Monnier @ 2020-04-24 6:51 ` Eli Zaretskii 2020-04-24 13:06 ` Stefan Monnier 0 siblings, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-24 6:51 UTC (permalink / raw) To: Stefan Monnier; +Cc: cpitclaudel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-24 6:51 ` Eli Zaretskii @ 2020-04-24 13:06 ` Stefan Monnier 2020-04-24 13:36 ` Eli Zaretskii 0 siblings, 1 reply; 88+ messages in thread From: Stefan Monnier @ 2020-04-24 13:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cpitclaudel, emacs-devel > 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-24 13:06 ` Stefan Monnier @ 2020-04-24 13:36 ` Eli Zaretskii 2020-04-24 15:13 ` Stefan Monnier 0 siblings, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-24 13:36 UTC (permalink / raw) To: Stefan Monnier; +Cc: cpitclaudel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-24 13:36 ` Eli Zaretskii @ 2020-04-24 15:13 ` Stefan Monnier 2020-04-24 15:46 ` Eli Zaretskii 0 siblings, 1 reply; 88+ messages in thread From: Stefan Monnier @ 2020-04-24 15:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cpitclaudel, emacs-devel > 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-24 15:13 ` Stefan Monnier @ 2020-04-24 15:46 ` Eli Zaretskii 0 siblings, 0 replies; 88+ messages in thread From: Eli Zaretskii @ 2020-04-24 15:46 UTC (permalink / raw) To: Stefan Monnier; +Cc: cpitclaudel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 14:46 ` Lars Ingebrigtsen 2020-04-23 15:00 ` Clément Pit-Claudel @ 2020-04-23 15:15 ` Eli Zaretskii 2020-04-23 15:17 ` Lars Ingebrigtsen 1 sibling, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-23 15:15 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: ndame, stefan, emacs-devel > 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? ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 15:15 ` Eli Zaretskii @ 2020-04-23 15:17 ` Lars Ingebrigtsen 2020-04-23 16:40 ` Yuan Fu 0 siblings, 1 reply; 88+ messages in thread From: Lars Ingebrigtsen @ 2020-04-23 15:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ndame, stefan, emacs-devel 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 15:17 ` Lars Ingebrigtsen @ 2020-04-23 16:40 ` Yuan Fu 0 siblings, 0 replies; 88+ messages in thread From: Yuan Fu @ 2020-04-23 16:40 UTC (permalink / raw) To: Lars Ingebrigtsen Cc: Eli Zaretskii, EMACS development team, Stefan Kangas, ndame > (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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 14:11 ` Stefan Kangas 2020-04-23 14:39 ` Clément Pit-Claudel 2020-04-23 14:46 ` Lars Ingebrigtsen @ 2020-04-23 15:09 ` Eli Zaretskii 2020-04-23 16:19 ` Stefan Kangas 2 siblings, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-23 15:09 UTC (permalink / raw) To: Stefan Kangas; +Cc: emacs-devel, ndame > 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? ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 15:09 ` Eli Zaretskii @ 2020-04-23 16:19 ` Stefan Kangas 2020-04-23 16:35 ` Stefan Kangas 0 siblings, 1 reply; 88+ messages in thread From: Stefan Kangas @ 2020-04-23 16:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ndame, Emacs developers 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 16:19 ` Stefan Kangas @ 2020-04-23 16:35 ` Stefan Kangas 0 siblings, 0 replies; 88+ messages in thread From: Stefan Kangas @ 2020-04-23 16:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ndame, Emacs developers > icons can work just as well, and on balance you have convinced me that ^^^^^ should be "images" ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 14:07 ` Stefan Kangas 2020-04-23 14:11 ` Stefan Kangas @ 2020-04-23 15:08 ` Eli Zaretskii 2020-04-23 15:49 ` Clément Pit-Claudel 1 sibling, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-23 15:08 UTC (permalink / raw) To: Stefan Kangas; +Cc: emacs-devel, ndame > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 15:08 ` Eli Zaretskii @ 2020-04-23 15:49 ` Clément Pit-Claudel 2020-04-23 16:34 ` Stefan Kangas 2020-04-23 19:12 ` Eli Zaretskii 0 siblings, 2 replies; 88+ messages in thread From: Clément Pit-Claudel @ 2020-04-23 15:49 UTC (permalink / raw) To: Eli Zaretskii, Stefan Kangas; +Cc: ndame, emacs-devel 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 15:49 ` Clément Pit-Claudel @ 2020-04-23 16:34 ` Stefan Kangas 2020-04-23 19:56 ` Clément Pit-Claudel 2020-04-23 19:12 ` Eli Zaretskii 1 sibling, 1 reply; 88+ messages in thread From: Stefan Kangas @ 2020-04-23 16:34 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: Eli Zaretskii, ndame, Emacs developers 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 16:34 ` Stefan Kangas @ 2020-04-23 19:56 ` Clément Pit-Claudel 0 siblings, 0 replies; 88+ messages in thread From: Clément Pit-Claudel @ 2020-04-23 19:56 UTC (permalink / raw) To: Stefan Kangas; +Cc: Eli Zaretskii, ndame, Emacs developers 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 15:49 ` Clément Pit-Claudel 2020-04-23 16:34 ` Stefan Kangas @ 2020-04-23 19:12 ` Eli Zaretskii 2020-04-25 2:55 ` Clément Pit-Claudel 1 sibling, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-23 19:12 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: ndame, stefan, emacs-devel > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 19:12 ` Eli Zaretskii @ 2020-04-25 2:55 ` Clément Pit-Claudel 2020-04-25 7:03 ` Eli Zaretskii 0 siblings, 1 reply; 88+ messages in thread From: Clément Pit-Claudel @ 2020-04-25 2:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ndame, stefan, emacs-devel 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-25 2:55 ` Clément Pit-Claudel @ 2020-04-25 7:03 ` Eli Zaretskii 2020-04-25 13:12 ` Clément Pit-Claudel 0 siblings, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-25 7:03 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: ndame, stefan, emacs-devel > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-25 7:03 ` Eli Zaretskii @ 2020-04-25 13:12 ` Clément Pit-Claudel 2020-04-25 13:18 ` Stefan Kangas 0 siblings, 1 reply; 88+ messages in thread From: Clément Pit-Claudel @ 2020-04-25 13:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ndame, stefan, emacs-devel 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-25 13:12 ` Clément Pit-Claudel @ 2020-04-25 13:18 ` Stefan Kangas 0 siblings, 0 replies; 88+ messages in thread From: Stefan Kangas @ 2020-04-25 13:18 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: Eli Zaretskii, ndame, Emacs developers 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-23 7:14 ndame 2020-04-23 7:25 ` ndame 2020-04-23 10:06 ` Stefan Kangas @ 2020-04-24 12:05 ` Eli Zaretskii 2020-04-24 15:11 ` ndame 2020-04-25 3:34 ` Richard Stallman 2 siblings, 2 replies; 88+ messages in thread From: Eli Zaretskii @ 2020-04-24 12:05 UTC (permalink / raw) To: ndame; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-24 12:05 ` Eli Zaretskii @ 2020-04-24 15:11 ` ndame 2020-04-24 15:45 ` Eli Zaretskii 2020-04-25 3:34 ` Richard Stallman 1 sibling, 1 reply; 88+ messages in thread From: ndame @ 2020-04-24 15:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 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? 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-24 15:11 ` ndame @ 2020-04-24 15:45 ` Eli Zaretskii 2020-04-24 16:07 ` Stefan Monnier 2020-04-25 3:38 ` Richard Stallman 0 siblings, 2 replies; 88+ messages in thread From: Eli Zaretskii @ 2020-04-24 15:45 UTC (permalink / raw) To: ndame; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-24 15:45 ` Eli Zaretskii @ 2020-04-24 16:07 ` Stefan Monnier 2020-04-24 16:29 ` Eli Zaretskii 2020-04-25 3:38 ` Richard Stallman 1 sibling, 1 reply; 88+ messages in thread From: Stefan Monnier @ 2020-04-24 16:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, ndame >> 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-24 16:07 ` Stefan Monnier @ 2020-04-24 16:29 ` Eli Zaretskii 0 siblings, 0 replies; 88+ messages in thread From: Eli Zaretskii @ 2020-04-24 16:29 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel, ndame > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-24 15:45 ` Eli Zaretskii 2020-04-24 16:07 ` Stefan Monnier @ 2020-04-25 3:38 ` Richard Stallman 2020-04-28 13:55 ` Robert Pluim 1 sibling, 1 reply; 88+ messages in thread From: Richard Stallman @ 2020-04-25 3:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, ndame [[[ 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) ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-25 3:38 ` Richard Stallman @ 2020-04-28 13:55 ` Robert Pluim 2020-04-28 14:38 ` Eli Zaretskii 0 siblings, 1 reply; 88+ messages in thread From: Robert Pluim @ 2020-04-28 13:55 UTC (permalink / raw) To: Richard Stallman; +Cc: Eli Zaretskii, ndame, emacs-devel >>>>> 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-28 13:55 ` Robert Pluim @ 2020-04-28 14:38 ` Eli Zaretskii 2020-04-29 12:30 ` Robert Pluim 0 siblings, 1 reply; 88+ messages in thread From: Eli Zaretskii @ 2020-04-28 14:38 UTC (permalink / raw) To: Robert Pluim; +Cc: emacs-devel, rms, ndame > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-28 14:38 ` Eli Zaretskii @ 2020-04-29 12:30 ` Robert Pluim 2020-04-29 14:00 ` Eli Zaretskii 0 siblings, 1 reply; 88+ messages in thread From: Robert Pluim @ 2020-04-29 12:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ndame, rms, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-29 12:30 ` Robert Pluim @ 2020-04-29 14:00 ` Eli Zaretskii 0 siblings, 0 replies; 88+ messages in thread From: Eli Zaretskii @ 2020-04-29 14:00 UTC (permalink / raw) To: Robert Pluim; +Cc: emacs-devel, rms, ndame > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-24 12:05 ` Eli Zaretskii 2020-04-24 15:11 ` ndame @ 2020-04-25 3:34 ` Richard Stallman 2020-04-25 6:39 ` Eli Zaretskii 1 sibling, 1 reply; 88+ messages in thread From: Richard Stallman @ 2020-04-25 3:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, ndame [[[ 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) ^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: High-res Customize icons 2020-04-25 3:34 ` Richard Stallman @ 2020-04-25 6:39 ` Eli Zaretskii 0 siblings, 0 replies; 88+ messages in thread From: Eli Zaretskii @ 2020-04-25 6:39 UTC (permalink / raw) To: rms; +Cc: emacs-devel, ndame > 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. ^ permalink raw reply [flat|nested] 88+ messages in thread
end of thread, other threads:[~2020-10-29 5:31 UTC | newest] Thread overview: 88+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-04-21 19:47 High-res Customize icons Yuan Fu 2020-04-22 2:23 ` Eli Zaretskii 2020-04-22 2:37 ` Clément Pit-Claudel 2020-04-22 5:47 ` chad 2020-04-22 12:24 ` Yuan Fu 2020-04-22 12:41 ` Yuri Khan 2020-04-22 13:54 ` Yuan Fu 2020-04-22 21:12 ` Juri Linkov 2020-04-22 22:20 ` Yuan Fu 2020-04-23 4:11 ` Werner LEMBERG 2020-04-23 14:52 ` Eli Zaretskii 2020-04-23 15:07 ` Clément Pit-Claudel 2020-04-23 17:49 ` Werner LEMBERG 2020-04-23 19:27 ` Eli Zaretskii 2020-04-23 19:35 ` Yuan Fu 2020-04-23 19:40 ` Eli Zaretskii 2020-04-23 19:59 ` Yuan Fu 2020-04-23 23:02 ` chad 2020-04-24 6:30 ` Eli Zaretskii 2020-04-24 11:00 ` Dmitry Gutov 2020-04-23 23:23 ` chad 2020-04-24 7:18 ` Eli Zaretskii 2020-04-25 3:30 ` Richard Stallman 2020-04-25 7:02 ` Eli Zaretskii 2020-04-25 12:37 ` Clément Pit-Claudel 2020-04-25 13:56 ` Eli Zaretskii 2020-04-22 13:35 ` Eli Zaretskii 2020-04-22 17:09 ` chad 2020-04-22 17:36 ` Eli Zaretskii 2020-04-22 18:28 ` chad 2020-04-22 18:38 ` Eli Zaretskii 2020-04-22 19:19 ` Yuan Fu 2020-04-22 19:28 ` Eli Zaretskii 2020-04-22 20:38 ` Yuan Fu 2020-05-01 13:46 ` Eli Zaretskii 2020-10-22 15:33 ` Yuan Fu 2020-10-23 16:39 ` Yuan Fu 2020-10-23 18:08 ` Eli Zaretskii 2020-10-27 19:17 ` Yuan Fu 2020-10-27 19:27 ` Eli Zaretskii 2020-10-27 22:26 ` Alan Third 2020-10-27 23:09 ` Yuan Fu 2020-10-28 0:05 ` Alan Third 2020-10-28 1:22 ` YAMAMOTO Mitsuharu 2020-10-29 5:31 ` Yuan Fu -- strict thread matches above, loose matches on Subject: below -- 2020-04-23 7:14 ndame 2020-04-23 7:25 ` ndame 2020-04-23 10:06 ` Stefan Kangas 2020-04-23 14:07 ` Stefan Kangas 2020-04-23 14:11 ` Stefan Kangas 2020-04-23 14:39 ` Clément Pit-Claudel 2020-04-23 14:46 ` Lars Ingebrigtsen 2020-04-23 15:00 ` Clément Pit-Claudel 2020-04-23 15:44 ` Stefan Monnier 2020-04-23 19:14 ` Eli Zaretskii 2020-04-23 20:33 ` Stefan Monnier 2020-04-24 6:51 ` Eli Zaretskii 2020-04-24 13:06 ` Stefan Monnier 2020-04-24 13:36 ` Eli Zaretskii 2020-04-24 15:13 ` Stefan Monnier 2020-04-24 15:46 ` Eli Zaretskii 2020-04-23 15:15 ` Eli Zaretskii 2020-04-23 15:17 ` Lars Ingebrigtsen 2020-04-23 16:40 ` Yuan Fu 2020-04-23 15:09 ` Eli Zaretskii 2020-04-23 16:19 ` Stefan Kangas 2020-04-23 16:35 ` Stefan Kangas 2020-04-23 15:08 ` Eli Zaretskii 2020-04-23 15:49 ` Clément Pit-Claudel 2020-04-23 16:34 ` Stefan Kangas 2020-04-23 19:56 ` Clément Pit-Claudel 2020-04-23 19:12 ` Eli Zaretskii 2020-04-25 2:55 ` Clément Pit-Claudel 2020-04-25 7:03 ` Eli Zaretskii 2020-04-25 13:12 ` Clément Pit-Claudel 2020-04-25 13:18 ` Stefan Kangas 2020-04-24 12:05 ` Eli Zaretskii 2020-04-24 15:11 ` ndame 2020-04-24 15:45 ` Eli Zaretskii 2020-04-24 16:07 ` Stefan Monnier 2020-04-24 16:29 ` Eli Zaretskii 2020-04-25 3:38 ` Richard Stallman 2020-04-28 13:55 ` Robert Pluim 2020-04-28 14:38 ` Eli Zaretskii 2020-04-29 12:30 ` Robert Pluim 2020-04-29 14:00 ` Eli Zaretskii 2020-04-25 3:34 ` Richard Stallman 2020-04-25 6:39 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.