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.

#OpenBSD now runs fd.o #fontconfig fc-cache(1) utility as an unprivileged '_fc-cache' user, dropping root privileges at both build time & at runtime (pkg_add). ​

bentley@ modified src/*: Change ownership of fontconfig cache to _fc-cache user.

ok kn@ deraadt@

bentley@ modified usr.sbin/pkg_add/OpenBSD/PackingElement.pm: When installing fonts, run fc-cache as the unprivileged _fc-cache user.

From espie; ok deraadt@

bentley@ modified xenocara/*: Don't perform font caching as root.

During build, run fc-cache as BUILDUSER.

When fc-cache is run as root, drop automatically to the _fc-cache user so /var/cache/fontconfig doesn't acquire root-owned files.

ok deraadt@

This nicely improves upon Anthony J. Bentley previous effort back in May, adding pledge(2) to fc-cache(1). ​

bentley@ modified xenocara/dist/fontconfig/fc-cache/fc-cache.c: Call pledge(2) in fc-cache(1): "stdio rpath wpath cpath flock".

ok deraadt