On Tue, Mar 29, 2022 at 07:33:27PM +0200, Quentin Rameau wrote:
> > On Mon, Mar 28, 2022 at 05:57:48PM +0600, NRK wrote:
> > > And on the topic of ellipsis_width, we currently don't account for
> > > fallback font:
> > >
> > > usedfont = drw->fonts;
> > > drw_font_getexts(usedfont, "...", 3, &ellipsis_width, NULL);
> > >
> > > The assumption here was that every font should have '.' but if that
> > > turns out to be wrong, then the font width will be incorrect.
>
> I think that we can have as a requirement that the system provides a
> font with the glyph for dot.
The issue was less about what's available *on the system* and more about
what was in `fonts[0]`.
I've looked into this matter a bit and turns out there's many icon/emoji
fonts which *intentionally* don't provide any latin (or other language)
glyphs, for example "Font Awesome".
Currently, dwm/dmenu allows for doing things like this:
static const char *fonts[] = {
"Icon Font", /* good icons, but does not have latin glyphs */
"Mono Font", /* has icons, but they're crappy looking */
};
In this case, "Icon Font" would be used for icons, while "Mono Font"
would be used as fallback for any latin chars. Swapping "Mono Font" to
be `fonts[0]` won't quite work because then, "Mono Font" will end up
getting used for icons as well.
The existing code assumes `fonts[0]` has `.` glyph and doesn't check for
any of the fallback fonts. The earlier patch I sent solves this issue,
and will now correctly calculate the `ellipsis_width` taking fallback
fonts into account.
- NRK
