>>>> "Nick" == Nick V Pakoulin
<npak(a)ispras.ru> writes:
Nick> Then the question is: is it possible to make KOI8-R to be
Nick> "basic cyrillic encoding" in MULE XEmacs? Ok, now I see the
Nick> problem -- KOI-8 does not have some characters that one can
Nick> find in oher cyrillic languages (like Ukranian).
Strictly speaking, this is not the reason that KOI8-R was not chosen.
The problem is that KOI8-R is not ISO-2022 compatible (taking the Mule
translation table seriously---I don't know where to find the standard
in English or Japanese ;). Working internally with non-ISO-2022
character sets in Mule is complicated, and effectively amounts to
translating them to ISO-2022 format anyway. So the Mule people chose
ISO-8859-5 which has several advantages: ISO-2022 compatibility (by
definition) and the other characters that you mention.
Nick> May be it is possible to make KOI*-R to be another cyrillic
Nick> charset, to be independent from iso8859?
This is possible, and I have already suggested it. However, it would
mean that KOI8-R could not easily be mixed with other Cyrillic
encodings due to the way Mule represents characters. If you cut from
a KOI8-R buffer and pasted in a ISO8859-5 buffer (not a realistic
example, I suppose, but for the sake of example), the resulting buffer
could not be portably saved to a file.
SJT> If you have an example of a multilingual app that works with
SJT> koi8-r, I'd like to know about it.
Nick> KDE2(qt-2.2.1) and KDE2 apps.
KDE/Qt is not going to happen soon for XEmacs/Mule due to the need for
a special internal representation. Presumably KDE does this using
Unicode internally and translation tables on output. XEmacs is moving
in that direction, but we can't use Qt functions in editing buffers
(even if we use the widgets, as in GTK XEmacs).
SJT> Does GNU Emacs do it correctly? If so, it should be possible
SJT> to port. Are there any tricks involved (eg, like using
SJT> unibyte buffers)?
Nick> Yes, GNU Emacs uses koi8-r fonts to display russian text.
Nick> For more details need some hackung :))
Is the hacking already in GNU Emacs, or is it separate? If separate,
where can I get it?
SJT> I would guess that would be acceptable (probably everybody
SJT> already uses KOI8 in their files); is it?
Nick> Well, most russian texts/files use three encodings: koi8-r,
Nick> windows-1251, alternativnaya(rare). Nobody uses iso8859-5
Nick> to write in russian.
OK.
How do people handle mixing Russian with languages that can't be
encoded in KOI8-R? Or is that sufficiently rare that nobody cares?
SJT> Also, how are the KOI8-R fonts specified under X and Windows? (I can't
SJT> do much about the latter, I don't know anything about Windows, but I can
SJT> at least document it for when somebody who does Windows wants to work on
SJT> it.)
Don't understand your question :(
For example, ETL uses the XLFD pattern -*-koi8-1 to mean KOI8-R. Are
there -*-koi8-r or -*-koi-0 etc kinds of patterns?
Normally Windows uses say "Western" or "Cyrillic". Probably you just
say the font is "Cyrillic" and use some internal magic to make sure
that the characters in the buffer are correctly mapped to font
indices, but I'd like to be able to document that for the Windows guys.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."