Re: Examining font properties under Windows

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

>>>>>> "Hrvoje" == Hrvoje Niksic <[email protected]> writes:
>
>     Hrvoje> The hairiest part might be looking up the appropriate
>     Hrvoje> font.  The lengths that x-face.el goes to to find a proper
>     Hrvoje> "larger" or "smaller" font are just scary.  But FSF
>     Hrvoje> manages to do it -- somehow.
>
> The last time I looked, GNU just punted.  The fact is that the "X
> Window System -- the de facto substandard" that Jamie rants about so
> entertainingly has grown up a lot.  If we could just get the
> children at XFree86 to behave ....  So you can actually expect X
> fonts to have fairly reliable properties most of the time for ISO
> 8859 Latin fonts, for example.  The GNU approach (again, last time I
> looked) would not have been satisfactory in 1993.

Good points, all.  I'd still feel safer if that kind of work were done
by someone who actually understood both the 1993 incantations *and*
the modern ones.

> I think all we really have to do is to turn the "font" property of a
> face into a cache for user specs given as XLFD or MSFT font names,
> and separate out all the other properties.

FSF sets `font' automatically based on family, etc., so the code that
examines it keeps working.  We could do the same.  Setting `font'
directly to XLFD is obsolete, but it can and should be respected.

The cache that maps face lists (with merged font-related properties)
to XLFD or whatever would be maintained internally, invisible to the
user.  It's a purely implementational issue.

I don't think the user should notice any difference between the
handling of "boldn" property and the handling of "underline" property
of a face.  In other words...

> This could be done reasonably in two ways that I can think of
> offhand.  The first is to create separate builtin (specifier)
> properties for each "important" property, with a plist for any
> secondary ones.

...I believe that all face properties should be treated equally
"important".  We might want to avoid having dozens of accessor and
mutator functions, for example by standardizing on `face-property'
(like FSF standardized on face-attribute) and declaring `face-*' and
`set-face-*' obsolete or semi-obsolete.

>     Hrvoje> I'm not sure I understand this.  Extents specify Emacs
>     Hrvoje> faces used in the buffer, when they're different from
>     Hrvoje> `default'.  On the other hand, face properties are
>     Hrvoje> stored in their respective specifiers, not in extents or
>     Hrvoje> anywhere else.
>
>     Hrvoje> Priority checking would work exactly like it does now, I
>     Hrvoje> think.
>
> OK.  But since font properties are currently merged as a block (ie, we
> instantiate the first whole font we encounter), we have to be careful
> to separate that out.  That's the main thing.

Agreed.  This separation is what I mean when I say that boldness and
such need to be first-class face properties.

Also note that FSF supports putting color and font specifications
directly in extents, e.g.:

    (put-text-property START END 'face '(:color "red" :slant italic))

I don't think we should support that.  We have temporary faces for
where that kind of thing is necessary.