bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Tim Ruffing]

To reproduce:
   1. `emacs` -Q on Linux with pgtk enabled
   2. `M-x select-frame-font` and select a font that doesn't have a
      bold weight
   3. Observe that the buffer indicator (`*scratch*`) in the status
      line is in bold (using synthetic bold glyphs)

This is annoying in combination with symbol fonts such as Nerd fonts.
The bold versions of some symbols look strange, and worse, they may be
too wide to fit two glyphs and are clipped then.

What I have tried:
 * I thought this is a font-config thing. /etc/fonts/conf.d by default
   has a symlink 90-synthetic.conf that sets the "embolden" attribute
   for font queries that ask for a bold font but only regular is
   available. Removing that symlink does make a difference when I try
   `fc-match "MY-FONT:weight=bold" --verbose | grep bold`. With the
   symlink, fc sets the embolden attribute, and without the symlink, it
   doesn't. I can even see the difference in emacs' (Pango) font
   selection dialog. But emacs itself doesn't seem to care about this
   and still creates a synthesized bold font. 
 * Cairo is supposed to pick this attribute up [1] and act accordingly,
   but that doesn't work. I tried to add a printf("synthesize: %d\n",
   cairo_ft_font_face_get_synthesize(font_face)); to the current emacs
   git (75fd7550ed6cede6c9e8224f1f2d62637c43fdd4) in ftcrfont_open, and
   this always prints "0" (even with the symlink in place!). AFAIU this
   means that Cairo should never embolden fonts, but some reason
   there's something in emacs that does it.  
 * describe-font only shows the medium/regular variant.  


[1]
https://gitlab.freedesktop.org/cairo/cairo/-/blob/master/src/cairo-ft-font.c#L1928-1936

In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
cairo version 1.17.8)
System Description: Arch Linux

Configured using:
'configure --with-pgtk --with-native-compilation=aot --sysconfdir=/etc
--prefix=/usr --libexecdir=/usr/lib --with-tree-sitter
--localstatedir=/var --with-cairo --disable-build-details
--with-harfbuzz --with-libsystemd --with-modules 'CFLAGS=-march=x86-64
-mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2
-Wformat -Werror=format-security -fstack-clash-protection
-fcf-protection -g
-ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto'
'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=auto'
'CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
-Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -g
-ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
value of $LC_COLLATE: de_DE.UTF-8
value of $LC_CTYPE: de_DE.UTF-8
value of $LC_MESSAGES: en_DK.UTF-8
value of $LC_MONETARY: de_DE.UTF-8
value of $LC_NUMERIC: de_DE.UTF-8
value of $LC_TIME: en_DK.UTF-8
value of $LANG: en_US.utf8
locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-
loaddefs
comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra
help-mode bytecomp byte-compile cl-lib sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/pgtk-win pgtk-win term/common-win pgtk-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads
dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
gtk pgtk lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 77248 5503)
(symbols 48 7107 0)
(strings 32 19670 2185)
(string-bytes 1 602889)
(vectors 16 15723)
(vector-slots 8 329133 12738)
(floats 8 27 46)
(intervals 56 270 0)
(buffers 984 12)

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Eli Zaretskii]

> From: Tim Ruffing <crypto@timruffing.de>
> Date: Wed, 13 Dec 2023 13:03:47 +0100
> 
> To reproduce:
>    1. `emacs` -Q on Linux with pgtk enabled
>    2. `M-x select-frame-font` and select a font that doesn't have a
>       bold weight
>    3. Observe that the buffer indicator (`*scratch*`) in the status
>       line is in bold (using synthetic bold glyphs)
> 
> This is annoying in combination with symbol fonts such as Nerd fonts.
> The bold versions of some symbols look strange, and worse, they may be
> too wide to fit two glyphs and are clipped then.
> 
> What I have tried:
>  * I thought this is a font-config thing. /etc/fonts/conf.d by default
>    has a symlink 90-synthetic.conf that sets the "embolden" attribute
>    for font queries that ask for a bold font but only regular is
>    available. Removing that symlink does make a difference when I try
>    `fc-match "MY-FONT:weight=bold" --verbose | grep bold`. With the
>    symlink, fc sets the embolden attribute, and without the symlink, it
>    doesn't. I can even see the difference in emacs' (Pango) font
>    selection dialog. But emacs itself doesn't seem to care about this
>    and still creates a synthesized bold font. 
>  * Cairo is supposed to pick this attribute up [1] and act accordingly,
>    but that doesn't work. I tried to add a printf("synthesize: %d\n",
>    cairo_ft_font_face_get_synthesize(font_face)); to the current emacs
>    git (75fd7550ed6cede6c9e8224f1f2d62637c43fdd4) in ftcrfont_open, and
>    this always prints "0" (even with the symlink in place!). AFAIU this
>    means that Cairo should never embolden fonts, but some reason
>    there's something in emacs that does it.  
>  * describe-font only shows the medium/regular variant.  

Thanks, but why do you think this is an issue for Emacs to solve?  I
don't think Emacs creates such "synthesized" fonts; are you sure it
does?  I think Emacs just asks fontconfig for a bold font; it has no
knowledge whether it gets a real or a synthetic font.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Tim Ruffing]

On Wed, 2023-12-13 at 14:39 +0200, Eli Zaretskii wrote:  
> I don't think Emacs creates such "synthesized" fonts; are you sure it
> does? I think Emacs just asks fontconfig for a bold font; it has no
> knowledge whether it gets a real or a synthetic font.

Well, *something* in the Emacs font rendering stack creates this bold
variant. font-config can't create it, it's just a config layer but
doesn't handle rendering. I'm really not an expert here with so many
pieces in the stack but AFAIU Cairo can be asked to do so, and will
just delegate to freetype. (Harfbuzz can also do it, see
https://github.com/harfbuzz/harfbuzz/pull/4097 , but I see the bold in
emacs when I configure --without-harfbuzz). 

The thing is: If I query font-config manually, it tells me to use the
regular font and not to embolden it (see below) .Emacs doesn't respect
this. 

So what we should have is a way to disable the emboldening. When I set
my font-config settings such that emboldening is disabled, pango
apparently respects this (as apparent from the font selection dialog)
but emacs doesn't.

A simple font for testing is this one here:
https://www.dafont.com/elronet-monospace.font

$ fc-match "ElroNet Monospace"
Elronmonospace.ttf: "ElroNet Monospace" "Normal"

But even when I ask for bold, there's no difference:

$ fc-match "ElroNet Monospace:bold"
Elronmonospace.ttf: "ElroNet Monospace" "Normal" 

When I have configured font-config to create bold:

$ fc-match "ElroNet Monospace:bold" --verbose | grep bold
	embolden: True(w)

When I haven't:
$ fc-match "ElroNet Monospace:bold" --verbose | grep bold

(no match)

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Eli Zaretskii]

> From: Tim Ruffing <crypto@timruffing.de>
> Cc: 67810@debbugs.gnu.org
> Date: Wed, 13 Dec 2023 14:28:58 +0100
> 
> On Wed, 2023-12-13 at 14:39 +0200, Eli Zaretskii wrote:  
> > I don't think Emacs creates such "synthesized" fonts; are you sure it
> > does? I think Emacs just asks fontconfig for a bold font; it has no
> > knowledge whether it gets a real or a synthetic font.
> 
> Well, *something* in the Emacs font rendering stack creates this bold
> variant. font-config can't create it, it's just a config layer but
> doesn't handle rendering. I'm really not an expert here with so many
> pieces in the stack but AFAIU Cairo can be asked to do so, and will
> just delegate to freetype. (Harfbuzz can also do it, see
> https://github.com/harfbuzz/harfbuzz/pull/4097 , but I see the bold in
> emacs when I configure --without-harfbuzz). 
> 
> The thing is: If I query font-config manually, it tells me to use the
> regular font and not to embolden it (see below) .Emacs doesn't respect
> this. 
> 
> So what we should have is a way to disable the emboldening. When I set
> my font-config settings such that emboldening is disabled, pango
> apparently respects this (as apparent from the font selection dialog)
> but emacs doesn't.

Maybe this is done by the calls to the font backend with FC_EMBOLDEN
parameter?  I'm no expert on these font backends, but maybe you could
play with those calls and see if disabling them gets you what you
want?  You can find the relevant code by searching the C sources for
FC_EMBOLDEN.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Tim Ruffing]

On Wed, 2023-12-13 at 15:39 +0200, Eli Zaretskii wrote:
> 
> Maybe this is done by the calls to the font backend with FC_EMBOLDEN
> parameter?  I'm no expert on these font backends, but maybe you could
> play with those calls and see if disabling them gets you what you
> want?  You can find the relevant code by searching the C sources for
> FC_EMBOLDEN.

Thanks for the suggestion, but no luck unfortunately. What also didn't
help is going back to Xft by configuring like this:
./configure --without-pgtk --without-cairo 

I don't know what to try next, I guess it will be useful to have
someone more familiar with the font stuff look at this. 

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Tim Ruffing]

Sorry for double posting but let me note that it would also be helpful
to know whether you or others can reproduce that behavior. This would
at least tell me that this is not something weird in my system config.
(I really don't think so, but you never know...)

Tim

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tim Ruffing <crypto@timruffing.de> writes:

> On Wed, 2023-12-13 at 15:39 +0200, Eli Zaretskii wrote:
>> 
>> Maybe this is done by the calls to the font backend with FC_EMBOLDEN
>> parameter?  I'm no expert on these font backends, but maybe you could
>> play with those calls and see if disabling them gets you what you
>> want?  You can find the relevant code by searching the C sources for
>> FC_EMBOLDEN.
>
> Thanks for the suggestion, but no luck unfortunately. What also didn't
> help is going back to Xft by configuring like this:
> ./configure --without-pgtk --without-cairo 
>
> I don't know what to try next, I guess it will be useful to have
> someone more familiar with the font stuff look at this. 

There's no bug here: when a bold face is displayed by a font which
doesn't provide a bold variant, Emacs overstrikes text displayed in that
font to create visual contrast between the bold text and its
surroundings.  This is implemented independently of font backend
features such as FC_EMBOLDEN.

If this contrast is undesirable, remove the weight attribute from the
face.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  67810@debbugs.gnu.org
> Date: Thu, 14 Dec 2023 08:09:11 +0800
> 
> Tim Ruffing <crypto@timruffing.de> writes:
> 
> > On Wed, 2023-12-13 at 15:39 +0200, Eli Zaretskii wrote:
> >> 
> >> Maybe this is done by the calls to the font backend with FC_EMBOLDEN
> >> parameter?  I'm no expert on these font backends, but maybe you could
> >> play with those calls and see if disabling them gets you what you
> >> want?  You can find the relevant code by searching the C sources for
> >> FC_EMBOLDEN.
> >
> > Thanks for the suggestion, but no luck unfortunately. What also didn't
> > help is going back to Xft by configuring like this:
> > ./configure --without-pgtk --without-cairo 
> >
> > I don't know what to try next, I guess it will be useful to have
> > someone more familiar with the font stuff look at this. 
> 
> There's no bug here: when a bold face is displayed by a font which
> doesn't provide a bold variant, Emacs overstrikes text displayed in that
> font to create visual contrast between the bold text and its
> surroundings.  This is implemented independently of font backend
> features such as FC_EMBOLDEN.

Can you point me at the place in the code where we do this?

> If this contrast is undesirable, remove the weight attribute from the
> face.

We could have a variable exposed to Lisp to inhibit this overstriking,
if some users want that.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Can you point me at the place in the code where we do this?

Yes, see lines 6192 and 6045 in xfaces.c, viz.:

  if (face->font
      && FONT_WEIGHT_NAME_NUMERIC (attrs[LFACE_WEIGHT_INDEX]) > 100
      && FONT_WEIGHT_NUMERIC (attrs[LFACE_FONT_INDEX]) <= 100)
    face->overstrike = true;

and

  face->overstrike
    = (! NILP (font_object)
       && FONT_WEIGHT_NAME_NUMERIC (face->lface[LFACE_WEIGHT_INDEX]) > 100
       && FONT_WEIGHT_NUMERIC (font_object) <= 100);

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Tim Ruffing]

@Po Lu:
Oh, thanks for pointing that out! I wasn't aware of the "overstrike"
term. I had grepped the code base for "bold" but I couldn't find
anything...

Okay, yes, so my use case is that I (or actually doom) uses this to
enable the display of icons:
  
(dolist (range '((#xe000 . #xf8ff) (#xf0000 . #xfffff)))
  (set-fontset-font t range "Symbols Nerd Font Mono"))

While overstriking is typically appropriate for normal fonts, it's
rather undesirable for others such as icons. For example, if the icon
contains a square, then the borders of the square are strechted
horizontally but not vertically. Moreover, this makes some glyphs to
wide and then their right side will be clipped. 

Removing the weight attribute from the face will only work in some
cases, e.g., for UI elements controlled by some package. If the user
inserts an icon in a bold org headline, we can't change the face on the
fly. (Well I'm sure, we could, but that sounds like the wrong
approach.)  

So I think whether overstriking is performed should ideally be a
property of the font. Having some variable similar to the existing 
vertical-centering-font-regexp would be great, and this would also make
it possible to turn off overstriking globally.

Do you think that's a reasonable thing to add?

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Eli Zaretskii]

> From: Tim Ruffing <crypto@timruffing.de>
> Cc: 67810@debbugs.gnu.org
> Date: Thu, 14 Dec 2023 10:54:45 +0100
> 
> So I think whether overstriking is performed should ideally be a
> property of the font. Having some variable similar to the existing 
> vertical-centering-font-regexp would be great, and this would also make
> it possible to turn off overstriking globally.
> 
> Do you think that's a reasonable thing to add?

What are the chances of someone wanting to disable this feature only
for some fonts?  If we want to allow disabling it globally, it should
be a simple matter of adding a boolean variable exposed to Lisp, and
then performing this only when the variable doesn't inhibit that.

Adding a font property, or a regexp for matching fonts which are
exempt from this, are by contrast much more complex and require more
changes.  For a feature that was so far requested by a single user,
I'm not sure this is justified.

As for your example: if Doom uses this for icons, why cannot Doom
refrain from using bold face for these cases?

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Tim Ruffing]

On Thu, 2023-12-14 at 12:04 +0200, Eli Zaretskii wrote:
> What are the chances of someone wanting to disable this feature only
> for some fonts?  If we want to allow disabling it globally, it should
> be a simple matter of adding a boolean variable exposed to Lisp, and
> then performing this only when the variable doesn't inhibit that.
> 
> Adding a font property, or a regexp for matching fonts which are
> exempt from this, are by contrast much more complex and require more
> changes.  For a feature that was so far requested by a single user,
> I'm not sure this is justified.
> 

My first intuition was that, conceptually, it should depend on the font
because it's desirable for some fonts but not for others, and I thought
the complexity is not that big given that we have the code essentially
in place, because we do the same for vertical centering.

But yeah, I expect the chances that someone wants to disable this only
for some fonts to be rather low: Fonts for "normal" text without bold
are very rare, and probably not high-quality anyway. So I don't think
there's anyone who has an advanced setup with icon fonts but at the
same time uses a poor font for normal text that doesn't even have a
bold variant, and then really needs the overstriking... (Plus, there
may be other mechanisms in that case, such as FC_EMBOLDEN).

For me personally, a boolean toggle will be fine, exactly for the
reason outline above: All the other fonts that I use have a bold
variant anyway. 

> As for your example: if Doom uses this for icons, why cannot Doom
> refrain from using bold face for these cases?

That's of course possible, and this could even be integrated in
packages like nerd-fonts and all-the-icons. But as I said in my
previous email, I think this solves only part of the problem. Setting
the face works when there is existing code for inserting icons (e.g.,
file type icons in dired), because that code can then take care of
setting the face. 

But it doesn't work in cases when the user simply wants to insert icons
in their buffers: For example, if the user inserts an icon in a bold
org headline, it seems to me like the wrong approach to change the face
on the fly.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Eli Zaretskii]

> From: Tim Ruffing <crypto@timruffing.de>
> Cc: luangruo@yahoo.com, 67810@debbugs.gnu.org
> Date: Thu, 14 Dec 2023 11:37:15 +0100
> 
> > As for your example: if Doom uses this for icons, why cannot Doom
> > refrain from using bold face for these cases?
> 
> That's of course possible, and this could even be integrated in
> packages like nerd-fonts and all-the-icons. But as I said in my
> previous email, I think this solves only part of the problem. Setting
> the face works when there is existing code for inserting icons (e.g.,
> file type icons in dired), because that code can then take care of
> setting the face. 
> 
> But it doesn't work in cases when the user simply wants to insert icons
> in their buffers: For example, if the user inserts an icon in a bold
> org headline, it seems to me like the wrong approach to change the face
> on the fly.

One can always insert an icon with the likes of

  (propertize "ICON" 'face '(:weight medium))

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tim Ruffing <crypto@timruffing.de>
>> Cc: 67810@debbugs.gnu.org
>> Date: Thu, 14 Dec 2023 10:54:45 +0100
>> 
>> So I think whether overstriking is performed should ideally be a
>> property of the font. Having some variable similar to the existing 
>> vertical-centering-font-regexp would be great, and this would also make
>> it possible to turn off overstriking globally.
>> 
>> Do you think that's a reasonable thing to add?

The only existing variable which controls font display through matching
fonts against a regexp has been effectively abandoned over the years,
and is nonfunctional on all systems besides X and Android.
(Grep for Vvertical_centering_font_regexp: only sfntfont.c and xfont.c
consult it.)

A compelling reason for us _not_ to introduce more such variables, as
they will soon fall into disuse and neglect.

> What are the chances of someone wanting to disable this feature only
> for some fonts?  If we want to allow disabling it globally, it should
> be a simple matter of adding a boolean variable exposed to Lisp, and
> then performing this only when the variable doesn't inhibit that.
>
> Adding a font property, or a regexp for matching fonts which are
> exempt from this, are by contrast much more complex and require more
> changes.  For a feature that was so far requested by a single user,
> I'm not sure this is justified.
>
> As for your example: if Doom uses this for icons, why cannot Doom
> refrain from using bold face for these cases?

Yes, and don't these packages require using their own specialized icon
fonts to begin with?

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Tim Ruffing]

On Thu, 2023-12-14 at 13:19 +0200, Eli Zaretskii wrote:
> One can always insert an icon with the likes of
> 
>   (propertize "ICON" 'face '(:weight medium))

Sure, but do you think that's a proper solution to add this whenever
buffer contents change? What if the user visits a file with an icon? I
don't know enough about the internals of emacs, but this still seems
the wrong approach to me?  

On Thu, 2023-12-14 at 19:26 +0800, Po Lu wrote:
> The only existing variable which controls font display through
> matching
> fonts against a regexp has been effectively abandoned over the years,
> and is nonfunctional on all systems besides X and Android.
> (Grep for Vvertical_centering_font_regexp: only sfntfont.c and
> xfont.c
> consult it.)
> 
> A compelling reason for us _not_ to introduce more such variables, as
> they will soon fall into disuse and neglect.
> 
> 

Makes sense. But then I suspect a boolean toggle is equally bad, as it
would equally fall into disuse.

> Yes, and don't these packages require using their own specialized
> icon fonts to begin with?

Yes, packages like all-the-icons and nerd-icons do require specialized.
fonts. But I'm not sure what this implies. What do you suggest that
these packages do?

I mean, a crude hack is to make emacs believe that the specialized
fonts are already bold. But even this is not too easy. AFAIU, this
cannot be done in elisp (because font objects are not modifiable), so
the packages can't do this emacs.

What one can always do is to distribute patched font files. I could
install a patched font of the icon font that claims it's bold. But
that's also a rather crude hack.

But thanks to your explanation, I managed to come up with a different
workaround. The following effectively makes emacs believe that the
fonts are bold without the need to patch a font


  <!-- Make fontconfig believe that this is a bold font.
       This prevents emacs from applying overstriking when trying to
       render bold icons.
       See: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67810

       Run `fc-cache -r` after making modifications here. -->
  <match target="scan">
    <test name="family" compare="contains">
      <string>Symbols Nerd Font</string>
    </test>
    <edit name="weight" mode="assign">
      <const>bold</const>
    </edit>
  </match>


That's still a bit crude due to the way emacs uses fontconfig. AFAIU
the way fontconfig typically is supposed to handle this is via
target="font" or target="match", i.e., the font is correctly parsed
into fontconfig's database but only when applications *query* for the
font, config tweaks apply and applications get a modified view, e.g.,
with weight=bold in this case. 

But this snippet here with target="scan" actually modifies the entry in
the fontconfig database because this is the only thing that works with
emacs. This is probably the same these two bugs:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25147 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=17792 .

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Stefan Kangas]

Tim Ruffing <crypto@timruffing.de> writes:

>> Yes, and don't these packages require using their own specialized
>> icon fonts to begin with?
>
> Yes, packages like all-the-icons and nerd-icons do require specialized.
> fonts. But I'm not sure what this implies. What do you suggest that
> these packages do?

They should use .svg files, I think.  See the branch scratch/icons for
the basic approach.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Tim Ruffing]

On Thu, 2023-12-14 at 14:55 -0800, Stefan Kangas wrote:
> 
> They should use .svg files, I think.  See the branch scratch/icons
> for
> the basic approach.

Yeah, that's a very clean approach, of course, but it's restricted to
graphical displays. And consideration went into the current design
described in 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Icons.html
which says "Icons should also have a textual fallback." and which has
an example with "textual" symbols. 

@Po Lu:
Independent of icons, I still think that overstriking is a bit
unexpected. (I mean, even Eli didn't know about it.) I see that a font
regex is too much, but do you think a simple boolean option would be a
good idea? Or do you think the current behavior should simply be
documented more prominently?

Tim

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tim Ruffing <crypto@timruffing.de> writes:

> Yeah, that's a very clean approach, of course, but it's restricted to
> graphical displays. And consideration went into the current design
> described in 
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Icons.html
> which says "Icons should also have a textual fallback." and which has
> an example with "textual" symbols. 

I suggest not using SVG icons for monochrome symbolic icons of the kind
doom-modeline often displays.  Libraries rendering SVG are relatively
memory-intensive and slow, while outline fonts are optimized for memory
consumption and scaler speed.

Incidentally, I've been toying with the idea of using the code in sfnt.c
to create vector symbols definable from Lisp and available on all
systems, to serve as fringe bitmaps and the like.

> @Po Lu:
> Independent of icons, I still think that overstriking is a bit
> unexpected. (I mean, even Eli didn't know about it.) I see that a font
> regex is too much, but do you think a simple boolean option would be a
> good idea? Or do you think the current behavior should simply be
> documented more prominently?

I think this is a mechanism users should not understand in this much
technical detail, because font backends might synthesize their bold or
oblique variants by other means when one is requested from a font that
doesn't provide them.  Rather, users should understand that Emacs will
seek to display bold text when they specify it should, and that text
which isn't meant to be bold text should not receive text properties
labeling it as such.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>   67810@debbugs.gnu.org
> Date: Fri, 12 Jan 2024 09:46:21 +0800
> 
> Tim Ruffing <crypto@timruffing.de> writes:
> 
> > @Po Lu:
> > Independent of icons, I still think that overstriking is a bit
> > unexpected. (I mean, even Eli didn't know about it.) I see that a font
> > regex is too much, but do you think a simple boolean option would be a
> > good idea? Or do you think the current behavior should simply be
> > documented more prominently?
> 
> I think this is a mechanism users should not understand in this much
> technical detail, because font backends might synthesize their bold or
> oblique variants by other means when one is requested from a font that
> doesn't provide them.  Rather, users should understand that Emacs will
> seek to display bold text when they specify it should, and that text
> which isn't meant to be bold text should not receive text properties
> labeling it as such.

Would it make sense to introduce a variable that disables synthesizing
bold or oblique font variants?

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: Stefan Kangas <stefankangas@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>>   67810@debbugs.gnu.org
>> Date: Fri, 12 Jan 2024 09:46:21 +0800
>> 
>> Tim Ruffing <crypto@timruffing.de> writes:
>> 
>> > @Po Lu:
>> > Independent of icons, I still think that overstriking is a bit
>> > unexpected. (I mean, even Eli didn't know about it.) I see that a font
>> > regex is too much, but do you think a simple boolean option would be a
>> > good idea? Or do you think the current behavior should simply be
>> > documented more prominently?
>> 
>> I think this is a mechanism users should not understand in this much
>> technical detail, because font backends might synthesize their bold or
>> oblique variants by other means when one is requested from a font that
>> doesn't provide them.  Rather, users should understand that Emacs will
>> seek to display bold text when they specify it should, and that text
>> which isn't meant to be bold text should not receive text properties
>> labeling it as such.
>
> Would it make sense to introduce a variable that disables synthesizing
> bold or oblique font variants?

I think it won't until someone informs us of how those features might be
disabled in the font drivers that perform this.  The Mac driver is
definitely one of them, and possibly the Fontconfig driver as well.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: crypto@timruffing.de,  stefankangas@gmail.com,  67810@debbugs.gnu.org
> Date: Fri, 12 Jan 2024 17:59:29 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Cc: Stefan Kangas <stefankangas@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
> >>   67810@debbugs.gnu.org
> >> Date: Fri, 12 Jan 2024 09:46:21 +0800
> >> 
> >> Tim Ruffing <crypto@timruffing.de> writes:
> >> 
> >> > @Po Lu:
> >> > Independent of icons, I still think that overstriking is a bit
> >> > unexpected. (I mean, even Eli didn't know about it.) I see that a font
> >> > regex is too much, but do you think a simple boolean option would be a
> >> > good idea? Or do you think the current behavior should simply be
> >> > documented more prominently?
> >> 
> >> I think this is a mechanism users should not understand in this much
> >> technical detail, because font backends might synthesize their bold or
> >> oblique variants by other means when one is requested from a font that
> >> doesn't provide them.  Rather, users should understand that Emacs will
> >> seek to display bold text when they specify it should, and that text
> >> which isn't meant to be bold text should not receive text properties
> >> labeling it as such.
> >
> > Would it make sense to introduce a variable that disables synthesizing
> > bold or oblique font variants?
> 
> I think it won't until someone informs us of how those features might be
> disabled in the font drivers that perform this.  The Mac driver is
> definitely one of them, and possibly the Fontconfig driver as well.

If we do introduce such a variable, wouldn't it prevent Emacs from
generating the missing variants?  And wouldn't avoiding to generate
them do what the OP wanted, i.e. have a default face's font where bold
looks like regular?

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> If we do introduce such a variable, wouldn't it prevent Emacs from
> generating the missing variants?

On the contrary: if the generation of such variants by the font backend
is inhibited, Emacs will display bold text with overstriking, when these
variants are absent from the font itself.

I should clarify that "generation" refers to the automatic generation of
oblique or bold fonts undertaken by a handful of our font backends, not
the overstriking implemented in xfaces.c.

> And wouldn't avoiding to generate them do what the OP wanted,
> i.e. have a default face's font where bold looks like regular?

No, see above.  However, the matter at hand is that I can't understand
the deficiency OPs request is supposed to address.  Surely, if the
author of a package which inserts icons wishes that they not be bold,
the package should set the face by which they are displayed to one that
isn't?

Thanks.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: crypto@timruffing.de,  stefankangas@gmail.com,  67810@debbugs.gnu.org
> Date: Fri, 12 Jan 2024 20:20:00 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If we do introduce such a variable, wouldn't it prevent Emacs from
> > generating the missing variants?
> 
> On the contrary: if the generation of such variants by the font backend
> is inhibited, Emacs will display bold text with overstriking, when these
> variants are absent from the font itself.
> 
> I should clarify that "generation" refers to the automatic generation of
> oblique or bold fonts undertaken by a handful of our font backends, not
> the overstriking implemented in xfaces.c.

Then we are mis-communicating, I think: I was talking about the code
in xfaces.c to which you pointed up-thread:

> > Can you point me at the place in the code where we do this?
> 
> Yes, see lines 6192 and 6045 in xfaces.c, viz.:
> 
>   if (face->font
>       && FONT_WEIGHT_NAME_NUMERIC (attrs[LFACE_WEIGHT_INDEX]) > 100
>       && FONT_WEIGHT_NUMERIC (attrs[LFACE_FONT_INDEX]) <= 100)
>     face->overstrike = true;
> 
> and
> 
>   face->overstrike
>     = (! NILP (font_object)
>        && FONT_WEIGHT_NAME_NUMERIC (face->lface[LFACE_WEIGHT_INDEX]) > 100
>        && FONT_WEIGHT_NUMERIC (font_object) <= 100);

I ws suggesting to introduce a variable that would inhibit this.

> > And wouldn't avoiding to generate them do what the OP wanted,
> > i.e. have a default face's font where bold looks like regular?
> 
> No, see above.  However, the matter at hand is that I can't understand
> the deficiency OPs request is supposed to address.  Surely, if the
> author of a package which inserts icons wishes that they not be bold,
> the package should set the face by which they are displayed to one that
> isn't?

AFAIU, the OP's request was to allow to have a default font that lacks
the bold variant, so that the bold face attribute could be displayed
in some other way, or maybe not at all.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> AFAIU, the OP's request was to allow to have a default font that lacks
> the bold variant, so that the bold face attribute could be displayed
> in some other way, or maybe not at all.

I thought the OP's difficulties related to the rendering of icon fonts
without bold variants displayed in contexts where the bold attribute is
generally applied, which if true it can be removed, after which the
world's your lobster.  Though if disabling the bold attribute for the
default face is indeed what OP wanted, providing this option exclusively
for fonts without bold variants (that is, subject to overstriking) would
create a fairly glaring deficiency.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: crypto@timruffing.de,  stefankangas@gmail.com,  67810@debbugs.gnu.org
> Date: Fri, 12 Jan 2024 21:12:40 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > AFAIU, the OP's request was to allow to have a default font that lacks
> > the bold variant, so that the bold face attribute could be displayed
> > in some other way, or maybe not at all.
> 
> I thought the OP's difficulties related to the rendering of icon fonts
> without bold variants displayed in contexts where the bold attribute is
> generally applied, which if true it can be removed, after which the
> world's your lobster.

Sorry, I don't understand what you are saying here.  Could you please
say it in simpler words?  What are "icon fonts"? and what do you mean
by "it can be removed"?

> Though if disabling the bold attribute for the default face is
> indeed what OP wanted, providing this option exclusively for fonts
> without bold variants (that is, subject to overstriking) would
> create a fairly glaring deficiency.

If we add such a variable, it will be opt-in behavior, so only users
who want it will get the behavior that you consider deficient.  It
will be then up to those users to decide whether the behavior is good
enough for them.  So I see no problem with such an option; we don't
have to like each and every optional behavior that is by default
turned off.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Sorry, I don't understand what you are saying here.  Could you please
> say it in simpler words?  What are "icon fonts"? and what do you mean
> by "it can be removed"?

Fonts designed to provide symbol icons, which are inserted by packages
that can control the `face' property of the text inserted.  Such fonts
don't provide bold variants, and they did prompt this bug report.

> If we add such a variable, it will be opt-in behavior, so only users
> who want it will get the behavior that you consider deficient.  It
> will be then up to those users to decide whether the behavior is good
> enough for them.  So I see no problem with such an option; we don't
> have to like each and every optional behavior that is by default
> turned off.

What if a user wants to disable the `bold' attribute for a font _with_
a bold variant?

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: crypto@timruffing.de,  stefankangas@gmail.com,  67810@debbugs.gnu.org
> Date: Sat, 13 Jan 2024 08:46:28 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Sorry, I don't understand what you are saying here.  Could you please
> > say it in simpler words?  What are "icon fonts"? and what do you mean
> > by "it can be removed"?
> 
> Fonts designed to provide symbol icons, which are inserted by packages
> that can control the `face' property of the text inserted.  Such fonts
> don't provide bold variants, and they did prompt this bug report.

So you are talking about fonts that use PUA codepoints to show icons?
Or are you talking about fonts whose glyphs for "normal" characters
(i.e. characters defined by the Unicode Standard) are replaced with
icons that look similarly?

> > If we add such a variable, it will be opt-in behavior, so only users
> > who want it will get the behavior that you consider deficient.  It
> > will be then up to those users to decide whether the behavior is good
> > enough for them.  So I see no problem with such an option; we don't
> > have to like each and every optional behavior that is by default
> > turned off.
> 
> What if a user wants to disable the `bold' attribute for a font _with_
> a bold variant?

That's not the feature I had in mind.  I don't see why Emacs should
allow users to disable font variants that do exist.  AFAIU, the
request was to prevent Emacs from creating a synthesized bold variant
if the font doesn't have it, and that's all.  How to find such a font
is a problem outside of Emacs's scope.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: crypto@timruffing.de,  stefankangas@gmail.com,  67810@debbugs.gnu.org
>> Date: Sat, 13 Jan 2024 08:46:28 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Sorry, I don't understand what you are saying here.  Could you please
>> > say it in simpler words?  What are "icon fonts"? and what do you mean
>> > by "it can be removed"?
>> 
>> Fonts designed to provide symbol icons, which are inserted by packages
>> that can control the `face' property of the text inserted.  Such fonts
>> don't provide bold variants, and they did prompt this bug report.
>
> So you are talking about fonts that use PUA codepoints to show icons?
> Or are you talking about fonts whose glyphs for "normal" characters
> (i.e. characters defined by the Unicode Standard) are replaced with
> icons that look similarly?

The former, yes.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: crypto@timruffing.de,  stefankangas@gmail.com,  67810@debbugs.gnu.org
> Date: Sun, 14 Jan 2024 09:02:17 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Cc: crypto@timruffing.de,  stefankangas@gmail.com,  67810@debbugs.gnu.org
> >> Date: Sat, 13 Jan 2024 08:46:28 +0800
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > Sorry, I don't understand what you are saying here.  Could you please
> >> > say it in simpler words?  What are "icon fonts"? and what do you mean
> >> > by "it can be removed"?
> >> 
> >> Fonts designed to provide symbol icons, which are inserted by packages
> >> that can control the `face' property of the text inserted.  Such fonts
> >> don't provide bold variants, and they did prompt this bug report.
> >
> > So you are talking about fonts that use PUA codepoints to show icons?
> > Or are you talking about fonts whose glyphs for "normal" characters
> > (i.e. characters defined by the Unicode Standard) are replaced with
> > icons that look similarly?
> 
> The former, yes.

OK, so what is the problem with allowing those users to have the
variable I proposed, for use with such fonts?

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> OK, so what is the problem with allowing those users to have the
> variable I proposed, for use with such fonts?

Because packages using such fonts should display these icons with a face
that isn't bold?  I don't understand why we should provide an option for
code which requests bold text to display such text in a normal font...if
that makes any sense.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: crypto@timruffing.de,  stefankangas@gmail.com,  67810@debbugs.gnu.org
> Date: Sun, 14 Jan 2024 16:09:10 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > OK, so what is the problem with allowing those users to have the
> > variable I proposed, for use with such fonts?
> 
> Because packages using such fonts should display these icons with a face
> that isn't bold?

There are faces that Emacs imposes that are not controlled by
packages.  For example, the buffer name on the mode line is displayed
in bold, and changing that is not easy.  Why cannot we allow users to
tweak this issue by providing a simple variable?  What are the
downsides?

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> There are faces that Emacs imposes that are not controlled by
> packages.  For example, the buffer name on the mode line is displayed
> in bold, and changing that is not easy.  Why cannot we allow users to
> tweak this issue by providing a simple variable?  What are the
> downsides?

It can't be guaranteed that this variable will work, because Emacs is
not the only program synthesizing bold variants from fonts that don't
incorporate them.  Moreover, little-used options that control these very
particular aspects of our font display tend to fall into disrepair: for
instance, Vvertical_centering_font_regexp didn't function on any system
besides X, until yours truly implemented it for Android, a state of
affairs that remained unnoticed for upwards of a decade.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: crypto@timruffing.de,  stefankangas@gmail.com,  67810@debbugs.gnu.org
> Date: Sun, 14 Jan 2024 21:44:53 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > There are faces that Emacs imposes that are not controlled by
> > packages.  For example, the buffer name on the mode line is displayed
> > in bold, and changing that is not easy.  Why cannot we allow users to
> > tweak this issue by providing a simple variable?  What are the
> > downsides?
> 
> It can't be guaranteed that this variable will work, because Emacs is
> not the only program synthesizing bold variants from fonts that don't
> incorporate them.  Moreover, little-used options that control these very
> particular aspects of our font display tend to fall into disrepair: for
> instance, Vvertical_centering_font_regexp didn't function on any system
> besides X, until yours truly implemented it for Android, a state of
> affairs that remained unnoticed for upwards of a decade.

I still don't understand what would be the downside of giving users
such a knob.  The worst that can happen is that this knob will
sometimes not work.  So what?

I say let's introduce it and let users who want to use it cope with
the results.  All it takes is a new DRFVAR and a single 'if'.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> I still don't understand what would be the downside of giving users
> such a knob.  The worst that can happen is that this knob will
> sometimes not work.  So what?

I thought we didn't want options that only work once in a blue moon, and
that only when Jupiter is aligned with the Galactic Center, or something
similarly rare, such as using the X core font backend.

> I say let's introduce it and let users who want to use it cope with
> the results.  All it takes is a new DRFVAR and a single 'if'.

I've expressed my objections, but if you're fine with the said
shortcomings, then I won't press the matter.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: crypto@timruffing.de,  stefankangas@gmail.com,  67810@debbugs.gnu.org
> Date: Sun, 14 Jan 2024 22:19:57 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I still don't understand what would be the downside of giving users
> > such a knob.  The worst that can happen is that this knob will
> > sometimes not work.  So what?
> 
> I thought we didn't want options that only work once in a blue moon, and
> that only when Jupiter is aligned with the Galactic Center, or something
> similarly rare, such as using the X core font backend.

We don't know what is the fraction of cases that this will work.  We
do know that sometimes it won't, but it could be "good enough".

> > I say let's introduce it and let users who want to use it cope with
> > the results.  All it takes is a new DRFVAR and a single 'if'.
> 
> I've expressed my objections, but if you're fine with the said
> shortcomings, then I won't press the matter.

I think we should provider such a variable, yes.  As long as it
doesn't require any further maintenance, I don't see any downsides.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Tim Ruffing]

On Sat, 2024-01-13 at 08:59 +0200, Eli Zaretskii wrote:
> > > 

> > What if a user wants to disable the `bold' attribute for a font
> > _with_
> > a bold variant?
> > 
> > That's not the feature I had in mind.  I don't see why Emacs should
> > allow users to disable font variants that do exist.  AFAIU, the
> > request was to prevent Emacs from creating a synthesized bold
> > variant
> > if the font doesn't have it, and that's all.  
> > 

Indeed.

@Po: And I totally agree that emacs packages who use icons from symbol
fonts should not set bold in the `face' property. However, as I said
earlier in this thread, I claim that this solves 90% of the cases, but
not all of them: Users may just want to insert icons in parts of their
files with bold font-lock, e.g., headings in org files or markdown
files (say you want to add a light-bulb icon in your notes for
"ideas"). In this case, while org-mode or markdown-mode (or actually
font-lock-mode) sets the bold face, these modes are not the ones that
insert the icon, so they shouldn't be responsible for setting regular
weight on icons. 

I claim that's a valid use case. Of course, one can totally object that
one should use SVGs, or that all of this is too niche so we shouldn't
care about this, and that even a boolean option is not worth the
complexity. And those are fine arguments, and after some more digging,
I'm also not sure anymore...  

Po wrote:
> > > Would it make sense to introduce a variable that disables
> > synthesizing
> > > bold or oblique font variants?
> > 
> > I think it won't until someone informs us of how those features
> > might
> > be
> > disabled in the font drivers that perform this.  The Mac driver is
> > definitely one of them, and possibly the Fontconfig driver as well.


In fact, now I thought a bit more about this, I agree with your
objections to having a simple knob that just disables overstriking in
xfaces.c... Yes, this would help some users, and it's easy to maintain,
but I suspect the behavior will be equally confusing to the current
one. (Think about a candidate docstring: "Inhibits the creation of
synthetic bold faces. This does not have an effect when the creation of
synthetic bolds is done by emacs font drivers, e.g., this variable has
no effect on Mac"... That is probably hard to understand for the
average user, and also it's simply not a solution for Mac users.)

I think you're right: If we want to add a boolean option, then it
should probably should cover all instances where emacs creates
synthetic bold fonts, i.e., not just the catch-all/fallback
overstriking in xfaces.c but also the synthetic bolds in the various
font drivers. (And the option should perhaps cover synthetic italics as
well, not sure. Or there could be a second option...) 

Yeah, then it's indeed more complex than a DEFSYM and two ifs. Though I
believe the complexity will still be manageable and also I don't think
we'll get bitten by this in the future: If this is an "inhibit"-style
option, the only risk is that we'll ever have font driver in the future
that creates synthetic bolds unconditionally.  

I had a look at the mentioned drivers.

For the MacOs driver, the property is set here in macfont.m, see uses
of synthetic_bold_p for the actual drawing. 

  if (!(sym_traits & kCTFontTraitBold)
      && FONT_WEIGHT_NUMERIC (entity) == FONT_WEIGHT_SYNTHETIC_BOLD)
    macfont_info->synthetic_bold_p = 1;

For Fontconfig / FT, "git grep -i embolden src" will point you to some
relevant code locations, but my digging shows that this driver will
never create synthetic bolds on demand. [1] 

So it's probably only overstriking and the font driver for MacOS that
would be affected by an option. 

Anyway, if people agree that an option should cover all drivers, the
patch is >5 lines and someone will need to work on it. I may have a
look in the future, but I currently don't have the time to work on it
(and I don't have a Mac, so someone else would need to test it.)  

Tim


[1] Okay, and this is where it's a bit of mess. 

While the code in the fontconfig driver doesn't have logic for creating
an synthetic bold variant when we want to display bold text, it
supports the "embolden" attribute that the user could set in their
config, at least kind of: If I set this in my local.conf for
fontconfig, then suddenly all fonts in all applications are synthetic
bolds, and emacs respects this, too.

<match target="font">
    <edit name="embolden" mode="assign">
      <bool>true</bool>
    </edit>
</match>

Of course, this is usually not meaningful. fontconfig ships with a
config file that is actually meaningful and enables synthetic bold
fonts when necessary, i.e., when no bold variant exists:

<match target="font">
    <!-- check to see if the weight in the font is less than medium
which possibly need emboldening -->
    <test name="weight" compare="less_eq">
        <const>medium</const>
    </test>
    <!-- check to see if the pattern requests bold -->
    <test target="pattern" name="weight" compare="more_eq">
        <const>bold</const>
    </test>
    <!--
      set the embolden flag
      needed for applications using cairo, e.g. gucharmap, gedit, ...
    -->
    <edit name="embolden" mode="assign">
        <bool>true</bool>
    </edit>
    <!--
     set weight to bold
     needed for applications using Xft directly, e.g. Firefox, ...
    -->
    <edit name="weight" mode="assign">
        <const>bold</const>
    </edit>
</match>

See the file 90-synthetic.conf, probably to be found in
/etc/fonts/conf.d .  But THAT setting one doesn't work in emacs. 

The reason is that fontconfig works in two steps:
1. build a database of fonts
2. let applications query the database with pattern matching

The second snippet above is supposed to have an effect in step 2. It
basically says "if the application queries for bold, and we don't have
native bold, set the embolden attribute in the query result".

But here's the thing: emacs will simply never ask for bold. What emacs
does is to ask fontconfig for the database resulting from step 1, and
the database doesn't have the bold font because it doesn't exist. So
emacs will learn that this is a font with weight "regular", and then
emacs will forever believe that the font is regular, and just simply
never query for a bold variant of it in step 2. This is just a
consequence of trying to fit fontconfig into the font driver model of
emacs. They use different concepts, and unless throw away all the emacs
font code, it just won't be possible to make fontconfig as in other
applications .

(See my message #47 in this thread for a way to get around this in
certain cases. One can set <match target="scan" ...> and this then will
influence step 1 and thus the database itself. But this is rather crude
and won't make the 90-synthetic.conf "on-demand" synthetic bold work:
We really need to compare the query pattern with the actual font to
determine whether embolden should be set. I said above that this is
also  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25147 and
 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=17792 , but now I
believe that this these were mostly fixed in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35781 already...)

The driver could, of course, set the embolden property automatically if
there's no native bold variant, and this would probably give a nicer
rendering than overstriking. Perhaps the driver should do this.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> I suggest not using SVG icons for monochrome symbolic icons of the kind
> doom-modeline often displays.  Libraries rendering SVG are relatively
> memory-intensive and slow, while outline fonts are optimized for memory
> consumption and scaler speed.

I've displayed many hundreds of SVG icons in an Emacs buffer without
running into any issues.  I therefore find the above claim surprising.

If you have any evidence that this is a problem in practice, then let's
see it.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefankangas@gmail.com> writes:

> I've displayed many hundreds of SVG icons in an Emacs buffer without
> running into any issues.  I therefore find the above claim surprising.
>
> If you have any evidence that this is a problem in practice, then let's
> see it.

It's easily demonstrable: open etc/images/splash.svg, zoom in and out
with the mouse wheel several times, and compare the image cache size in
M-x memory-report with the same after repeating the test with
etc/images/splash.xpm.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> I've displayed many hundreds of SVG icons in an Emacs buffer without
>> running into any issues.  I therefore find the above claim surprising.
>>
>> If you have any evidence that this is a problem in practice, then let's
>> see it.
>
> It's easily demonstrable: open etc/images/splash.svg, zoom in and out
> with the mouse wheel several times, and compare the image cache size in
> M-x memory-report with the same after repeating the test with
> etc/images/splash.xpm.

I'll take your word for it.  Do you understand why this happens?

What can we do to improve the situation?

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefankangas@gmail.com> writes:

> I'll take your word for it.  Do you understand why this happens?

Each time an SVG image is loaded, a bitmap the size of the scaled image
is allocated and cached, then copied onto the frame whenever the SVG
must be displayed.  This bitmap is retained for 300 seconds, during
which any number of other bitmaps might be allocated, which eventually
come to occupy most available X server memory.

The same goes for other image formats in principle, but in practice SVG
images are the most susceptible to runaway memory consumption, since the
dimensions of the bitmap cached in the course of displaying an SVG image
match its dimensions on-screen, which can be quite the beast on dense
displays or when scale factors are enabled for related reasons.

> What can we do to improve the situation?

A shorter default image cache retention time, without question, and
perhaps better criteria for deciding when to flush it.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> I'll take your word for it.  Do you understand why this happens?
>
> Each time an SVG image is loaded, a bitmap the size of the scaled image
> is allocated and cached, then copied onto the frame whenever the SVG
> must be displayed.  This bitmap is retained for 300 seconds, during
> which any number of other bitmaps might be allocated, which eventually
> come to occupy most available X server memory.
>
> The same goes for other image formats in principle, but in practice SVG
> images are the most susceptible to runaway memory consumption, since the
> dimensions of the bitmap cached in the course of displaying an SVG image
> match its dimensions on-screen, which can be quite the beast on dense
> displays or when scale factors are enabled for related reasons.
>
>> What can we do to improve the situation?
>
> A shorter default image cache retention time, without question, and
> perhaps better criteria for deciding when to flush it.

Yes.  As Eli explained to me in bug#68006 (correct me if I'm wrong), the
image cache was designed to work with the display engine (for icons and
toolbars).  For other usage, like image-mode for instance, we might need
something else.
-- 
Manuel Giraud

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> Yes.  As Eli explained to me in bug#68006 (correct me if I'm wrong), the
> image cache was designed to work with the display engine (for icons and
> toolbars).  For other usage, like image-mode for instance, we might need
> something else.

I understand you haven't made reference to the provisions for
user-specified image caches that you have proposed in that thread, but
it's still relevant that although such provisions will work in
image-mode's favor, they cannot resolve the memory consumption problems
inherent in the practice of caching scaled SVG images in the first
place.

Or on the flip side, performance degradation incurred by calling into
SVG for many dozens of small icons, which are removed from the image
cache after the eviction delay elapses without regard to their size or
the frequency at which they are invoked.

Worse yet, the display connection is cut when the image cache consumes
all bitmap memory allotted by the X server to Emacs.  This generates an
asynchronous Alloc error that Emacs is not in a position to detect until
it next returns to the event loop.

With the size of images as they exist today, and the density of the
devices on which they are displayed, I think that caching complete
images for N number of seconds has become an outmoded solution for not
loading images redundantly.  It's unpleasant for increasing
doc-view-resolution to force you to hold your breath before typing "n"
in a DocView buffer, out of a sense of apprehension that the subsequent
page might be sufficiently large to trigger such an error.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

> Manuel Giraud <manuel@ledu-giraud.fr> writes:
>
>> Yes.  As Eli explained to me in bug#68006 (correct me if I'm wrong), the
>> image cache was designed to work with the display engine (for icons and
>> toolbars).  For other usage, like image-mode for instance, we might need
>> something else.
>
> I understand you haven't made reference to the provisions for
> user-specified image caches that you have proposed in that thread, but
> it's still relevant that although such provisions will work in
> image-mode's favor, they cannot resolve the memory consumption problems
> inherent in the practice of caching scaled SVG images in the first
> place.

Yes scaled SVG tend to take much space but in the example you gave (zoom
in and out of a SVG in image-mode), I think it has more to do with the
cache not being adapted for such usage: the fact that an image spec
contains its size and is retain for 300 seconds by default (as you
said).

> Or on the flip side, performance degradation incurred by calling into
> SVG for many dozens of small icons, which are removed from the image
> cache after the eviction delay elapses without regard to their size or
> the frequency at which they are invoked.

Ok but is there such usage of SVG icons into Emacs?  If there is it
would require a much more smarter cache or, even better, a fast
rasterizer.

> Worse yet, the display connection is cut when the image cache consumes
> all bitmap memory allotted by the X server to Emacs.  This generates an
> asynchronous Alloc error that Emacs is not in a position to detect until
> it next returns to the event loop.
>
> With the size of images as they exist today, and the density of the
> devices on which they are displayed, I think that caching complete
> images for N number of seconds has become an outmoded solution for not
> loading images redundantly.  It's unpleasant for increasing
> doc-view-resolution to force you to hold your breath before typing "n"
> in a DocView buffer, out of a sense of apprehension that the subsequent
> page might be sufficiently large to trigger such an error.

I've never hit this case but I don't have a high density display.  Is it
something that happen to you regularly?
-- 
Manuel Giraud

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> Yes scaled SVG tend to take much space but in the example you gave (zoom
> in and out of a SVG in image-mode), I think it has more to do with the
> cache not being adapted for such usage: the fact that an image spec
> contains its size and is retain for 300 seconds by default (as you
> said).

The format of the keys used by the image cache is not at fault here,
since cached copies of SVG images must match their display sizes
regardless of whether the image cache is sensitive to sizes in image
specs specifying other image types.

> Ok but is there such usage of SVG icons into Emacs?  If there is it
> would require a much more smarter cache or, even better, a fast
> rasterizer.

Not as yet, but it's being proposed.

> I've never hit this case but I don't have a high density display.  Is it
> something that happen to you regularly?

It was until I reset doc-view-resolution to 100.

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

[...]

>> Ok but is there such usage of SVG icons into Emacs?  If there is it
>> would require a much more smarter cache or, even better, a fast
>> rasterizer.
>
> Not as yet, but it's being proposed.

You mean that you're working on a new SVG rasterizer?  If so, great!

>> I've never hit this case but I don't have a high density display.  Is it
>> something that happen to you regularly?
>
> It was until I reset doc-view-resolution to 100.

I don't know about your setup but if you use mupdf as a converter it
could convert documents to SVG image (see 'doc-view-mupdf-use-svg').

AFAIU, in this case the 'doc-view-resolution' is not used anymore…  But,
yes, zooming in and out will result in big rasterized version in the
image cache.
-- 
Manuel Giraud

bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
> [...]
>
>>> Ok but is there such usage of SVG icons into Emacs?  If there is it
>>> would require a much more smarter cache or, even better, a fast
>>> rasterizer.
>>
>> Not as yet, but it's being proposed.
>
> You mean that you're working on a new SVG rasterizer?  If so, great!

Alas, no.  I was referring to increasing the number of SVG icons loaded
by Emacs.

> I don't know about your setup but if you use mupdf as a converter it
> could convert documents to SVG image (see 'doc-view-mupdf-use-svg').

Thanks.  I will see if it is possible to install mupdf here.