• st
• dwm
• Firefox
• Senpai IRC
• Geany
• websites/forums

Sigh, I wasted* hours hacking on #fontconfig, trying to make it be a better Windows citizen, and it is just horrible.

Apparently it was written back in the last years of the 1900s in what was supposed to be a very "portable" fashion, where "portability" then meant "run on any random hardware and Unix-like OS/environment with ancient C compilers that possibly could run the X Window System", and it has not been cleaned up since then.

For instance, what is the point with using this FcChar8 type, a typedef for unsigned char, and thus having to cast back and forth to char all the time whenever calling C library functions? What's wrong with using plain char?

(Sure, char might be signed or unsigned, but when manipulating strings that seldom matters. For actual arithmetics on chars, in those few code snippets where that is done, it could then use casts to unsigned char. Using FcChar8 all over the place is just bonkers.)

The Windows portability bits, at least partially written by my younger self over 20 years ago, use only "narrow" character APIs for pathname related APIs, which by now is deeply troubling.

Windows NT is the only type of Windows that remains. (Windows 2000 → XP → Vista → 7 → 8 → 10 → 11). Its file systems use UTF-16 for names, and to be able to access all files and folders one needs to use wide character APIs. Like _wopen() instead of open(), and FindFirstFileExW() instead of FindFirstFileEx().

Should I even bother trying to upstream improvements, or just do the bare minimum to make it work properly in non-ASCII situations in the new Collabora Office? Upstreaming fixes cleanly and properly will take a lot of time. Not interested enough to spend much own time on this, more than I already did.

The principle in a fontconfig cleanup for file names on Windows should be: Keep using plain narrow char strings, as for Unix, to avoid massive changes all over it, but assume/ensure they are in UTF-8 on Windows, and convert to/from UTF-16 only right before/after calling C library or Win32 APIs that take/return pathnames.

I wonder how much FLOSS software nowadays uses fontconfig on Windows? Probably more than I think. Which means a potential upstreaming of Windows-related improvements must be careful not to break such use.

*) Not actually ”wasted”, any investigation and experimentation where you learn things is useful.

fontconfigのこの問題は、いつまで放置するんだろうね。16年も放置されたままというのは、やっぱり異常だよ #linux #fontconfig

65-nonlatin should be updated for CJK fonts (\#53) · Issue · fontconfig/fontconfig: https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/53

I have managed to break my #Linux system, because I used Font Manager to deactivate most of the pre-installed #fonts. I despise font cruft.

BUT, that means that the configuration files for the #fontconfig subsystem are not referencing any of the fonts I actually have installed and activated, so when I installed Font Awesome 6 for a particular #Conky config I downloaded, other applications started using Font Awesome as their default font for sans-serif.