bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Po Lu
Subject: bug#67810: 29.1; fonts use synthetic bold on Linux / pgtk
Date: Fri, 12 Jan 2024 09:46:21 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]