Re: gtk mule-fonts note

Moving discussion to xemacs-beta. The reason for using this tag is to tell Custom _not_ to clear those fonts from the faces. I don't know what Custom currently does, but its attitude had always been "ALL FACES YOURS NOW FACES OURS ARE", and it freely trashed anything it doesn't recognize as being specific to some package. The way to associate a font with a charset is simply to use an XLFD that matches that charset. The match is defined by the 'registry property of the charset. For example (charset-registry 'ascii) => "\\(iso8859-[0-9]*\\|-ascii\\)" (charset-registry 'latin-iso8859-15) => "iso8859-15" Probably the first one should be fixed to match "iso646-irv" as well. Specifier tags are semantically significant to XEmacs core only when they "match" a specific device. If any of the tags do not match a particular device, then that specification will not be used on that device. For this reason, specifier tag definitions tend to collect in device initialization code, although when used as "ids" for a particular module's specifications there is no need for that. It's also true that whether or not Mule is implemented has historically been strongly associated with specific device types. Ilya> You mean device type? Then the reason is that lisp code Ilya> defining the tag is executed only when initializing devices Ilya> of that type. This was a partial cleanup by Ben. But he never had the problems with Custom trashing his faces, so he may or may not have been aware of the need for a specifier tag to protect non-ASCII/Latin-1 fonts from Custom. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.