Re: Examining font properties under Windows

Please consolidate to xemacs-design; reply-to set (use narrow reply). Hrvoje> make-face-family (who the hell invented *that* name? Hrvoje> **set**-face-family, anyone?) must go away if we're to Hrvoje> have a sane face API. Jan V, I think. Parallel to make-face-{bold,italic}? Hrvoje> because the `bold' face should be nothing other than a Hrvoje> face with the `bold' property set to t, such as the Hrvoje> temporary I generated with `make-face' in the above Hrvoje> example. Of course, the second form works even now, but Hrvoje> with subtly different semantics: it draws all characters Hrvoje> in the buffer with *the same* font: that of the `bold' Hrvoje> face. Bad. The semantics we have now are due to the fact that specifier inheritance is not properly implemented, I believe. Hrvoje> If it sounds hairy for the display code to merge fonts on Hrvoje> the fly, it may be true. AFAICT most of the hair is already in the code. I think that probably Ben's code suffers from premature optimization here. ;-) Hrvoje> After having seen how it works in Emacs 21, I don't have a Hrvoje> problem with "faces" equally treating font properties Hrvoje> (size, weight, slant) and non-font ones (color, underline, Hrvoje> antialiasing). OK, so you want it to be the case that a face is a set of properties merged from the current context. I don't see why the current face cachels can't be used to keep things reasonably efficient, but the merging process may be more complex. I don't really know. I'll be looking for it, while I place with Xft. It would help if you could check me on all the places that might hold face properties (specifier locales, but also extents; anything else?), and think about how precedence should work (specifiers are set up to check the greatest preceding containing extent in display order, snarf all relevant data for the specifiers found there with the usual precedence for specifier domains). I think the current precedence is probably right, but we should think about it. While I'm here ... I think it would be easy to create a mode locale for specifiers. This would be checked after buffers but before frames. I think that the use of buffer locale is almost always a proxy for a mode locale, anyway. Another random thought: under Xft (not fontconfig this time, Xft) consing up a font is cheap because all font configuration and glyph construction is done client-side, no X protocol roundtrips involved. (Xft uses Xrender protocol to draw glyphs, not {Image,Poly}Text{8,16}.) Of course we can't put that in the bank and write checks on it for a production XEmacs yet, but we should keep it in mind. Hrvoje> Ouch. Have you tried talking to Mr. Handa and Stallman Hrvoje> about it? No, because it's all going to change when emacs-unicode gets merged to mainline anyway. I keep meaning to look