GNU bug report logs - #67810
29.1; fonts use synthetic bold on Linux / pgtk

Previous Next

Full log

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

From: Tim Ruffing <crypto <at> timruffing.de>
To: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 67810 <at> debbugs.gnu.org
Subject: Re: bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk
Date: Thu, 14 Dec 2023 16:06:32 +0100

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 .

Previous Next

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