Re: [PATCH] (Draft) Make X11 server-side fonts and Mule suck less.

Ar an t-aonú lá déag de mí Lúnasa, scríobh Stephen J. Turnbull: Han characters are a rotten idea if you have a standard spoken language anyway; the Koreans did it right. (Which is not to say that they needed to establish a national character standard with all the precombined Jamo instead of leaving the combining to software ...) The registry and encoding in the XLFD will be frobbed--which is a good thing, it’s the only way to automatically find the font that is identical to the default font face except that its registry and encoding reflect the desired charset--so that will do it almost all of the time. A charset’s registries look like this: (charset-registries 'japanese-jisx0208) => ["jisx0208.1983-0" "jisx0208.1990-0" "jisc6226.1978-0"] The “almost all” above comes into play when the user specifies a font with a given registry and encoding for a charset (say, "jisc6226.1978-0" for japanese-jisx0208), gives its full XLFD, and another font, identical in XLFD to the desired one except that its registry comes before that of the desired font in (charset-registries 'japanese-jisx0208), is available on the X server. This will be a minor problem at best, since the repertoires will be ~identical; if a particular user prefers a particular registry and encoding, re-ordering the charset registries for the charset before font instantiation with (set-charset-registries []) will allow that. If a particularly contrarian user prefers a particular encoding for once face’s font and another for another face’s font, and both fonts have otherwise identical XLFDs with both registry-encoding combinations, then that user is probably out of luck with this patch, just as before it. (I say “probably” and mean it to apply to both cases, because I can think of possible solutions both before the patch and after it, but have no desire to fuck around with fonts.dir and so on to check them--this is a really marginal case.) If the opportunity to use a legacy Japanese X11 installation arises, I would appreciate a list of the registries and encodings and the corresponding Japanese Mule character sets there. Yeah, I’m using symbols instead of numbers anyway, so I’ll avoid that terminology for the docstrings. With X11 server-side fonts, however, since searching by repertoire is impossible without hard-coding repertoire information--I intend doing the weak version of this, that is, keeping Markus Kuhn’s Unicode XLFDs around as the best fallback for charset lookups that would otherwise fail--the difference can only be theoretical. I’ve been working with the Win32 build recently, and this isn’t particularly well implemented there, which would seem to imply that it’s non-trivial. I have fonts on this system that support Thai, Arabic, Ethiopic, Greek and Russian, and it doesn’t find them, while Firefox does. Not before any release, I imagine. And we are going to have to keep around the Mule charsets in some form for for ISO 2022 support and X11 server-side font redisplay; using them now gives a useful improvement in functionality without much work. I agree that it’s right; I do wonder why you’re not using vararg versions of those macros, since anyone living on the edge enough to play with XFT support certainly has a compiler that supports them, they are cleaner, and my patch of 2005-01-17 used them, so it’s not for want of knowing about them. Try doing either over the network! Nine seconds each for me when the data needs to find its way to Dublin. Though I haven’t tested if it’s better with this patch, My perception of the regex code is, yes, that it’s REALLY DAMN SLOW. The same operation (with the list of fonts initialised by hand) is instantaneous for on GNU Emacs, so it’s nothing fundamental, just some apparently long-standing rottenness in our code. -- Santa Maradona, priez pour moi!