There are cases where the xft unofficial patch for dmenu renders the text with the wrong encoding. This happens when no xft font is loaded. Reproducible: Always Steps to Reproduce: 1. Install dmenu with xft use flag 2. Run on terminal: echo áóéí | dmenu 3. Watch the rendered text. Actual Results: The rendered text is in the wrong encoding. Expected Results: The rendered text to look as 'áóéí'. Without xft patch $ echo áóéí | dmenu -> OK With xft patch $ echo áóéí | dmenu -> fails $ echo áóéí | dmenu -fn "Terminus-10:normal" -> OK
Created attachment 348772 [details, diff] Proposed xft patch This patch is supossed to substitute the already existing patch for xft. The patch proposes to switch the order of 'if' sentences in 'initfont'/'loadfont' functions.
Comment on attachment 348772 [details, diff] Proposed xft patch I'd rather fix this in the ebuild as upstream is pretty sure to not accept patches that use pkgconfig...
While working on this, I saw that USE=xinerama is broken too - it actually requires that we add append-cflags -DXINERAMA for it to work as intended. Also, your patch doesn't actually change anything compared to the patch we already apply, except the config.mk stuff which I am working on getting fixed in the ebuild.
(In reply to comment #3) > Also, your patch doesn't actually change anything compared to the patch we > already apply, except the config.mk stuff which I am working on getting > fixed in the ebuild. I may have missed some bits there in my initial review. Apart from the config.mk/pkg-config changes, I think your patch should probably be reviewed upstream.
I didn't any changes to config.mk compared to the existing patch.
Let's give this a spin. The patch is at work in 4.5-r3.
