Re: [hackers] [libsl|dmenu][PATCH v2] Fix truncation issues and improve performance

From: NRK <nrk_AT_disroot.org>
Date: Wed, 30 Mar 2022 21:06:53 +0600

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
Received on Wed Mar 30 2022 - 17:06:53 CEST