In article <[EMAIL PROTECTED]>, "Jan D." <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
