Ar an t-aonú lá déag de mí Márta, scríobh Stephen J. Turnbull:
>>>>> "Stefan" == Stefan Holst
<holst(a)mathematik.uni-mainz.de> writes:
Stefan> The "greek" characters get displayed nicely in the chosen
Stefan> tt-font, wheras the mathematical operator leads to the
Stefan> warning:
Stefan> (12) (font/notice) Unable to instantiate font for charset
Stefan> chinese-gb2312, face default
Hm. I think that what needs to happen here is for the font instiation
code to go back and check for the character as a singleton. This will
take a couple of days, as will looking at your x-smbol-for-unicode
stuff.
The font instantiation code is only called the first time a character from a
given character set is accessed for a given font, and the XFT font chosen
for some text is, as a result, intimately dependent on that text’s Mule
character set. Changing that would involve much restructuring of the
redisplay code, and would probably be a big performance hit, for a
short-term improvement in display.
Stefan, you can add support for those characters to your XFT build by
following a procedure detailed here;
http://cvs.xemacs.org/viewcvs.cgi/XEmacs/xemacs/src/unicode.c.diff?r1=1.2...
You will also need to call set-language-unicode-precedence-list to move the
Mule character set you create before any other character sets that have
those symbols available. Give me a shout of what I’ve just written isn’t
clear enough.
This is just another reason for us to move away from the Mule internal
encoding. Real Soon Now.
I also really need to synch up sjt-xft to 21.5.20 (which will be
released shortly) as it has a really critical fix to the lstream
code. I'll probably get to the stuff that you're interested in first,
though.
--
“I, for instance, am gung-ho about open source because my family is being
held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle,
when we say something in public? No-one!” -- Danny O’Brien