On Fri, 20 Feb 2015 19:53:04 -0800
Eric Pruitt <eric.pruitt_AT_gmail.com> wrote:
Hi Eric,
> First off, I'm not sure what's proper etiquette around here for posting
> a public email that is somewhat directed toward a specific person, so
> mea culpa if CC'ing that person is the wrong approach.
it bugs me when people send a mail to the ml and CC me as well, but that
depends on personal taste.
I spend my time reading each mail here, so given the suckless-ml is not
high volume, I think CC'ing is not that important.
However, your consideration is valid, given this is the usual approach
for instance on the OpenBSD-mailing-lists and I can imagine that
Christoph Lohmann, who probably has numerous more mailing lists to
follow than me, might have a different opinion on this.
> The Xft / Fc* font calls end up returning the default font even though
> the codepoint does not exist in it. This is the first time I've done
> anything with Xft, so I'm not sure if there's something that can be done
> with the Fc* calls to keep this from happening.
I must admit that I personally am not happy with the font-cache in st.
For each character drawn, it is checked if it is in the current fontset.
If not, some fontconfig-magic happens in the background, selecting a
font which contains the character.
A few months ago I spent an evening rewriting the fontconfig-backend so
that you would specify _two_ fonts in the config.h (font[] and fontfb
[]). Usually, in a terminal emulator, you need your font for daily
usage and one "default" font which has all the Unicode characters.
I understand fontconfig's approach to take every font in scope of the
system in regard, but for a terminal emulator, this is too complex and
I bet also a speed implication.
Dropping the fontconfig-magic and only falling back if a Rune is not in
the current font dropped a lot of code in my case.
In config.def.h, the fallback font fontfb[] could already be set to some
sane default font everybody has and which has a big range of
Unicode-characters.
What do the others think?
Cheers
FRIGN
--
FRIGN <dev_AT_frign.de>
Received on Sat Feb 21 2015 - 15:00:05 CET