[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: what is the status of the XFT branch?
From: |
Kenichi Handa |
Subject: |
Re: what is the status of the XFT branch? |
Date: |
Tue, 18 Apr 2006 16:21:21 +0900 |
User-agent: |
SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/22.0.50 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) |
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