Re: what is the status of the XFT branch?

[Kenichi Handa]

In article <address@hidden>, "Jan D." <address@hidden> writes:

> Kenichi Handa wrote:
>> 
>> Actually, after reading codes of XFT branch, I started to
>> design a new font handling mechanism.  The basic plan is to
>> use multiple font-backends drivers (xcore, xft, windows,
>> bdf, atm, etc).  The main motivation for this rewriting is
>> that the current XFT code in the branch is very difficult to
>> utilize fontconfig's help for font selection, and to drive
>> OTF fonts.  And also, I want to clean up the current fairly
>> complicated font related codes (including many HAVE_XFT
>> conditionals, many XLFD parsing code, etc).

> This is a good idea, currently Emacs have too much XLFD knowledge builtin 
> (i.e. in face specifications) which makes the XFT code more complicated.

Yes.  And, I think this can be the first step toward the
integeration of *term.c.

>> But, as there are many other works to be done, the progress
>> for the above code is slow.  Please don't expect a quick
>> response on this matter.  Anyway, here's the current font.h
>> file (not yet fully considered) with which you may get a
>> feeling of the design.
>> 

> At first glance it looks good.  I guess the details will
> work themselves out when this is applied to various font
> mechanisms.  I imagine some things that are available for
> some font drivers are not available for others.

Yes, perhaps.  I have no knowlege about Windows font and ATM
font.

> Maybe there is a bit of speed overhead also, as current
> Emacs accesses the X font struct directly.  But I guess it
> wont be noticable.

I guess so too.

---
Kenichi Handa
address@hidden