Re: X fontomania

>>>>> "Matthias" == Matthias Neubauer <[email protected]> writes:

    Matthias> I would agree with you that the situation as it is is a
    Matthias> big mess. But in my opinion, the problem right now is
    Matthias> (almost) totally independent whether we use Xft fonts or
    Matthias> not.

I'm not particularly interested in Xft _fonts_ (except that they _are_
pretty).  It's _fontconfig_ that has properties that might be useful
in organizing what XEmacs needs to know about fonts.

    Matthias> To me, the code for buffer text selection seems like a
    Matthias> wild hack that combines both types of font/color
    Matthias> selection in some magical ways that I do not understand.

It's not that bad.  ;-)

    Matthias> On the other hand, the code for the toolbars, menus and
    Matthias> so on (i.e. the stuff in lwlib) exclusively uses X
    Matthias> Ressources to specify the properties and X Intrinsics
    Matthias> routines to do the selection. I.e. (almost) nothing is
    Matthias> done manually.

And almost nothing can be done manually from Lisp, cf my example of
wanting to change the color of a toolbar button.

    Matthias> So my first question would be if there is any general
    Matthias> (existing) scheme how the interplay of selections by
    Matthias> faces and by X Resources is resolved right now?

No, there isn't.  The problem is that Xt doesn't provide any
reasonable way to specify resources for dynamically created objects.
So basically we convert to faces early if we have X resources (and of
course afterwards it's not possible to change X resources).

    Matthias> Is there a scheme to eliminate all the X resources
    Matthias> completely by simply translating them into faces first?

faces.el, init-face-from-resources.

    Matthias> If so, where do I find it in the code exactly? Finally,
    Matthias> which parts are (best) coded in C, and which in Emacs
    Matthias> Lisp?

Tastes vary.  See my reply to Mike; my taste, and his, I think, is to
put as much in Lisp as possible---but Ben made exactly the opposite
choice.

    Matthias> Before integrating all that "mess" into lwlib as well, I
    Matthias> would rather like to see that this part gets cleaned up
    Matthias> first.

The reason I'm thinking about doing it at the same time is that I
don't have a clear concept of what the _needs_ are; if I try to
integrate faces into lwlib, then I'll know what needs to be exported
from faces.c, etc.

This will also avoid duplicating all the code you guys have written
for buffers/windows.

    Matthias> (Up to now, I added the Xft fonts to the menubars and
    Matthias> the buffer tabs in such a way that you also only can
    Matthias> specify them by X Resources.)

Yup, me too.  But I want faces so that we can do I18N of the menubars
etc from Lisp; currently they have to be done from X resources and use
X Font Sets (yuck).

    Matthias> I wouldn't say so. I thought color specifiers used in
    Matthias> faces are only symbols like "red" or "grey80", aren't
    Matthias> they?

They can be anything that X11 understands (such as hex integers).  I
don't think XEmacs understands the X Color Management System, though.
But Xft has nicer colors, in particular with alpha channel.

    Matthias> (BTW, this is one part where I had no clue about the
    Matthias> 16-bit case when working on the Xft integration. In
    Matthias> src/redisplay-x.c, before some text is printed, it is
    Matthias> first split up in several "runs", each run is converted
    Matthias> by some magic "ccl program",

Actually, the ccl program is never called for any standard charset.
The only one I know where it is used is for KOI8.

    Matthias> and then depending on its "dimension" printed either
    Matthias> with XftDraw*8 or XftDraw*16. Does this already
    Matthias> guarantee that encondings other than 8859-1 are always
    Matthias> translated to "dimension 2", i.e. Unicode?)

No, dimension 2 is a charset-specific encoding, just like
iso-8859-[2,...15].  There's Japanese, and two flavors of Chinese, and
Korean, and all of these have multiple components.

    >> Right.  Currently, this is done in the font-specifier code but
    >> only on MS Windows.  On X it wants to match the registry in the
    >> XLFD, but that sucks[tm] for several reasons.  This should be
    >> fairly easy to implement, though.  I think only
    >> x_font_spec_matches_charset in objects-x.c needs to be changed,
    >> and I can have Japanese in Xft.

    Matthias> If you selected the right font with the correct char
    Matthias> set, and if the "ccl program" I mentioned above was
    Matthias> doing the right translation to Unicode, this should work
    Matthias> right away ...

No, the ccl program here has nothing to do with Unicode; it's intended
to translate from non-ISO charsets to ISO variants and back.  Use the
functions in unicode.c (char_to_ucs and ucs_to_char).


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.