Sujet : Re: font fallback issues
De : candycanearter07 (at) *nospam* candycanearter07.nomail.afraid (candycanearter07)
Groupes : comp.os.linux.miscDate : 28. May 2024, 00:30:05
Autres entêtes
Organisation : the-candyden-of-code
Message-ID : <slrnv5a5os.8c8.candycanearter07@candydeb.host.invalid>
References : 1 2 3 4 5
User-Agent : slrn/1.0.3 (Linux)
Nuno Silva <
nunojsilva@invalid.invalid> wrote at 19:15 this Saturday (GMT):
On 2024-05-24, Lawrence D'Oliveiro wrote:
>
On Fri, 24 May 2024 17:40:06 -0000 (UTC), candycanearter07 wrote:
>
Well, I read that most Linux apps use fontconfig for font rendering ...
>
Fontconfig is used for matching fonts, not for the actual rendering.
>
But it's this matching that at least selects fonts. I have some settings
for antialiasing and hinting in its configuration file too (although
these days it's more complicated to guess where that file goes, given
they seem to have changed to $XDG_CONFIG_HOME). So fontconfig can at
least control that (settings) in some cases. (I probably have settings
for the same purpose but for Xft in $HOME/.Xdefaults.)
>
Now can fontconfig control replacement too?
>
But, yes, another challenge is that not everything will go via
fontconfig, maybe the best approach is to try to "merge" the replacement
fonts and the main font in a single font, so that there's no question of
how will the fallback be handled?
Maybe, but I'm not sure how..
-- user <candycane> is generated from /dev/urandom
font fallback issues
Re: font fallback issues