Ar an chéad lá de mí Márta, scríobh Francois Maltey: Almost certainly an error in the XFT branch. Could you select the following, press C-x C-e, try to reproduce the problem, and tell me what happens? (fset 'xfd-xlfd-font-name-p 'xft-font-name-p) -- “I, for instance, am gung-ho about open source because my family is being held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle, when we say something in public? No-one!” -- Danny O’Brien

Thanks a lot Aidan Indeed Now I get xft-font-real-pattern undefined when I open this mail. Have a good day ! François, from France.

Aidan> Actually, don’t even do this--there are too many functions Aidan> used without being defined in that file. I’ll check in an Aidan> update to lisp/fonts.el to fix that soon. sjt> Yeah, I suspect this is fallout from Eric Knauel's checkin a sjt> while back. I'm seeing these, too. Oops. This is my bad, and the reason I only started seeing these "recently" is because I switched over to a pristine workspace. My old workspace has those fixes in it already. I don't know whether I screwed the checkin or CVS did. You can belay the request to delay checkin of your patch, it's just what I should have done months ago. This still holds: fonts.el is a real mess, and I _do not_ want things fixed just so that people can use Xft in production. If people can't hack around this stuff for themselves, Xft is not ready for them yet. Although more precisely fonts.el isn't too bad; it's the relationships among fonts.el, faces.el, x-faces.el, etc that are screwed. -- 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. -- 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.

Ben, all this is proposed for my sjt-xft branch, but your comments and warnings about any conflicts/redundancy with work you're doing would be greatly appreciated. Eric> Yes, it's a mess. (And add fontmenu.el to the list.) Some Eric> opaque type for specifing and modifying a font in a Eric> device-independent faishon would be helpful. I don't think it needs to be all that opaque, it just needs to disaggregate font specifications instead of passing around platform-specific strings. Here's what I propose to do. (All would be done on the sjt-xft branch.) Create a fontconfig.el which will emulate the fontconfig APIs we expose to Lisp (it can be trivial, just a hashtable with string keys and list or vector values will do, I think), and redo all the font manipulations in those terms. The Xft/fontconfig C code will Fprovide 'fontconfig, so as long as nobody `load's fontconfig.el we'll be fine. (In the long run we'll have to come up with something more robust, or maybe starting by splitting into fontconfig.el and fontconfig-api.el for the emulation is a good idea.) This will bring us more in line with GNU Emacs APIs (although it won't directly provide them, it will make it easier). Nuke font.el entirely. Anything useful in it goes into fontconfig.el, and the color stuff should emulate the Xrender color API (I think, need to look at Windows and Carbon), and be somewhere else. (Cf lwlib/lwlib-colors.[ch], too.) I'd like to nuke the Lisp_Font_Instance object. It's only used in a small number of places. I've already been bitten badly once by fontconfig's overloading of font patterns to be both patterns and fonts, and the Lisp level use of font instances is more of the same. I don't have a specific proposal, but that's a medium term goal for me. In a related but technically independent task: Looking at the face cache code, it looks to me like internal font instances should grow a charset_spec member. The charset_spec should be a Lisp_Object for flexibility, then it can contain an integer (charset ID/leading byte), a Lisp charset, a Lisp chartable, an FcCharSet, an FcLANG, or whatever. More careful spec and optimization later. Then the font[] member of struct face_cachel becomes a list rather than charset-keyed dictionary. Redisplay will compute a desired charset for the character, then walk the font list, and take the first font that handles a superset. If not, try to instantiate such a font from the specifier, and add it at the end of the list. If not, walk it again, and take the first font that handles the character itself, If not, try to instantiate such a font from the specifier, and add it to the end of the list (FIXME: some chance of mixed priorities here, but I think adding such fonts with nil as charset does the right thing, or pretty close). And if not, substitute U+FFFD in the rune (but not in the string or buffer!) I've already started on both tasks, but not gotten very far. Comments welcome, or if somebody's going in the same direction, let's talk and not duplicate effort/create unnecessary CVS conflicts. I will summarize as a patch to Future Work in internals.texi. -- Institu