>> For example, Japanese CJK characters are represented with the
>> SimSun font on my computer.
>
> I am wondering how much of this behavior depends on display (and the
> availability of a display with fontsets, etc).
It *completely* depends on display! You can control the fonts by
setting them up, either using the FontConfig interface or directly
handling X11 font names.
> I have moved on a bit since the last time I wrote. I have switched
> over to use get-text-property. That seems to be better and more
> consistent than char-charset. char-charset in emacs 23 can return
> different things based on priority - that's frustrating - I wonder
> if there is a "compatibility mode".
AFAIK, there isn't. I think we should *only* rely on
get-text-property.
> The string returned by get-test-property is not exactly the same as
> char-charset - e.g. 'tis620-2533' vs 'thai-tis620',
I've just loaded CJKbabel.tex into a buffer, positioned the cursor on
a Thai character, called `eval-expression' and evaluated
(get-text-property (point) 'charset)
==> thai-tis620
So I think we can use this, right?
However, this result
(char-charset (point))
==> unicode
I get for all characters in the buffer, which doesn't help at all.
(I'm running an almost recent bzr version of Emacs, BTW. No idea
whether this differs for Emacs 23 versions).
> and 'nil' for ascii region instead of 'ascii'.
This is OK, I think.
> The other thing is, there seems to be some buffer confusion and once
> in a while things switch to a different buffer, and/or the buffer
> pointer got winded back.
No idea what you are talking about.
> Perhaps I could ask: how often does the code backtrack in the input
> buffer scan? It certain does in the Thai part. It is easier to
> deal with skipping over a chunk of input than it backtracking over
> and over :-(.
How is this relevant to the problem? Please explain.
Werner
_______________________________________________
Cjk maillist - Cjk@ffii.org
https://lists.ffii.org/mailman/listinfo/cjk
