On Mon, 19 Oct 2015 12:53:50 +0300 Ilias Tsitsimpis <i.tsitsim...@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
