Re: X fontomania

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

>>>>>> "Matthias" == Matthias Neubauer
>>>>>> <[email protected]> writes:
>
>     Matthias> Can you elaborate a little bit what you mean by "making
>     Matthias> faces work right"? Is this in the context of all those
>     Matthias> ugly Emacs Lisp faces functions?
>
> They're ugly because the problems are hard, I think.  I'm currently
> toying with replacing the font-related stuff in the faces with the
> fontconfig model, at least where Xft is available.  But fontconfig is
> not sufficiently powerful to replace font specifiers, I think---I'll
> end up with font specifiers managing fontconfig objects.

If I understood font specifiers correctly, they establish a
1:1-relation between a device-type and some kind of a font description
(i.e. the core font name as a string).  However, the Xft-patch
introduces a second kind of font description for the same device type.
This causes some confusion and is a source of evil hacks like our
font-description-type-detection-by-regexp-matching-hack (see
xft-xlfd-font-name-p in xft-fonts.c).

IMHO there needs to be some abstraction to help distinguish these font
descriptor types.  One could invent a `x-font-description' record type
with subtypes for Xft and Core fonts along with a set of generic
operations on x-font-descriptions (the fontconfig pattern functions
might serve as a template).  All stuff related to manipulating font
descriptions would reside in one location then.  At the moment this is
spread all over the code, which is, given a second kind of font
descriptions, not a clean solution.  From my (little) experience with
Xft and the font menu, I would suggest to wrap the fontconfig objects
in some x-font-description records before storing them in a font
specifier and provide fontconfig-like manipulation functions for
x-font-description records (of both subtypes).

-Eric
-- 
"Excuse me --- Di Du Du Duuuuh Di Dii --- Huh Weeeheeee\" (Albert King)