On Mon, 19 Oct 2015 12:53:50 +0300
Ilias Tsitsimpis <i.tsitsimpis_AT_gmail.com> wrote:
> I noticed that dmenu doesn't complain when supplied with a font that
> doesn't exist (e.g., dmenu -fn suckless).
>
> I found the following line in the code:
>
> drw.c:134 fprintf(stderr, "error, cannot load font: '%s'\n",
> fontname);
It looks like that line of code will never be executed as long as
xft can find a usable font. According to
http://stackoverflow.com/a/17176477 , that's the intended behavior and
nobody will fix it.
"4. forget about matching a specific font file. fontconfig will actively
fight any attempt to work this way. In the post-core-fonts world, you
give the font system a font pattern, and it will build a matching font
for you. If the result is not the font file you expected that's because
the file was evaluated and found lacking."
Actually, they say to not use xft directly at all...
Apparently, the xft(3) man page is wrong:
"XftFontOpen takes a list of pattern element triples of the form
field, type, value (terminated with a NULL), matches that
pattern against the available fonts, and opens the matching font,
sizing it correctly for screen number screen on display dpy. The
Display data type is defined by the X11 library. Returns NULL if no
match is found."
Not sure what to do about this... I like to know when the specific font
I asked for doesn't exist or can't be loaded. I guess the only thing
you can do is verify that it's the right font by its appearance?
--
Matt Boswell
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - and proprietary attachments
Received on Mon Oct 19 2015 - 19:53:59 CEST