Re: Examining font properties under Windows

"Stephen J. Turnbull" <[email protected]> writes:

>     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.  ;-)

I don't see anything optimal about that code.  :-)

It's not really an optimization matter at all.  The display code
already assembles face lists and memoizes them into more efficient
data structures that contain fonts and everything.  Font merging is
only one more thing to do as part of that process, and it only has to
be done once per face list.

>     Hrvoje> After having seen how it works in Emacs 21, I don't have
>     Hrvoje> a problem with "faces" equally treating font properties
>     Hrvoje> (size, weight, slant) and non-font ones (color,
>     Hrvoje> underline, antialiasing).
>
> OK, so you want it to be the case that a face is a set of properties
> merged from the current context.

I try to reserve the term "face" for Emacs faces, whose properties are
stored in specifiers.

The "set of properties used to render text" is really assembled at
display-time from all the faces that apply to the region, which are
they are in turn retrieved by merging the face properties from all the
extents that overlap the region.

XEmacs already does all this for colors and underlining and such, but
we don't define mergable properties relating to fonts.

> 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.

The hairiest part might be looking up the appropriate font.  The
lengths that x-face.el goes to to find a proper "larger" or "smaller"
font are just scary.  But FSF manages to do it -- somehow.

> It would help if you could check me on all the places that might hold
> face properties (specifier locales, but also extents; anything else?),

I'm not sure I understand this.  Extents specify Emacs faces used in
the buffer, when they're different from `default'.  On the other hand,
face properties are stored in their respective specifiers, not in
extents or anywhere else.

Priority checking would work exactly like it does now, I think.