Re: Examining font properties under Windows

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

>     Hrvoje> FSF sets `font' automatically based on family, etc., so
>     Hrvoje> the code that examines it keeps working.  We could do the
>     Hrvoje> same.  Setting `font' directly to XLFD is obsolete, but it
>     Hrvoje> can and should be respected.
>
> You mean to the extent that the XLFD can be parsed into a set of
> properties, right?

Probably.  If the user specifies XLFD, we should destructure it for
the sake of merging, but use it unchanged when merging is not
required.  I can elaborate if this is unclear.

>     Hrvoje> for example by standardizing on `face-property' (like FSF
>     Hrvoje> standardized on face-attribute) and declaring `face-*' and
>     Hrvoje> `set-face-*' obsolete or semi-obsolete.
>
> Why not `face-attribute'?

Because face-attribute doesn't know anything about specifiers.  If
we're importing their function, we should import their semantics as
well.  I know *I* hate when FSF reuses our function name, but changes
the meaning.

>     Hrvoje> Also note that FSF supports putting color and font
>     Hrvoje> specifications directly in extents, e.g.:
>
> Actually, I like that API.  If the face is temporary, I don't see
> why it needs to be explicit or have a name.

Because:

* It's useful to have faces internally for storage about the stuff
  they specify.

* They allow a mixture of lists of faces and such specifications that
  can be very hard to understand in the general case.  In XEmacs, the
  `face' property can be either a face or a list of faces.  In FSF, it
  can be a face, a list of faces, a special list that's conceptually
  one face, or a list that mixes normal faces and such special lists.

  They should have used vectors, like jwz did with keymaps and Ben
  with glyphs.  It would have been much easier to distinguish the two.

* It's useful for things to have names, even if they're produced by
  `gensym'.  At least it would have spared the author of htmlize some
  headaches.  :-)

> I've toyed with the idea that there should be an "extent" specifier
> locale.

Why for heavens sake?  :-(  The specifier stuff is too hard to
understand as it is.