Re: Examining font properties under Windows

Please consolidate to xemacs-design; reply-to set (use narrow reply).

>>>>> "Hrvoje" == Hrvoje Niksic <[email protected]> writes:

    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.

    >> for the similar functions in XEmacs -- it's incomplete, a hack,
    >> doesn't really address the needs (of Mule users, in my case).

    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