On Fri, Apr 29, 2022 at 08:11:46AM +0200, Laslo Hunhold wrote: > to keep a long story based on my experience with developing libgrapheme > and intensely working with Unicode short: The char-width-data from the > Unicode consortium cannot be relied on and said consortium has pretty > much given up on this matter and delegated this to font-rendering and > font-shaping implementations. While they still maintain the EAW-tables > (among others), they are nothing more than heuristics that break > horribly in many cases.
In that case, I think it's best to rule option 3 (codepoint width) and 2 (strlen) entirely. I forgot to add the patch for option 1 (not taking fallback fonts into account). Attached it here, it should apply cleanly on top of the patch I sent earlier regarding not calculating `inputw` when using vertical mode. - NRK
>From 820a56238fdcc392442fc35026915abf7f8fad52 Mon Sep 17 00:00:00 2001 From: NRK <[email protected]> Date: Fri, 29 Apr 2022 09:03:48 +0600 Subject: [PATCH] inputw: stop taking fallback font into account incorrect, but taking fallback fonts into account causes massive startup slowdown when the input strings have many missing glyphs. --- dmenu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/dmenu.c b/dmenu.c index 6b02b2b..75a81c2 100644 --- a/dmenu.c +++ b/dmenu.c @@ -675,7 +675,9 @@ setup(void) } promptw = (prompt && *prompt) ? TEXTW(prompt) - lrpad / 4 : 0; for (item = items; !lines && item && item->text; ++item) { - if ((tmp = textw_clamp(item->text, mw/3)) > inputw) { + drw_font_getexts(drw->fonts, item->text, strlen(item->text), &tmp, NULL); + tmp = MIN(mw/3, tmp + lrpad); + if (tmp > inputw) { if ((inputw = tmp) == mw/3) break; } -- 2.35.1
