7:22 p.m.
Ar an naoú lá déag de mí Eanair, scríobh Mike FABIAN:
It is probably not possible to handle U+00B1 as double width in
XEmacs
and handle German Umlauts as single width at the same time.
“Handle” is a bit ambiguous there. All the following characters are distinct
within XEmacs, but identical in Unicode (select the expression and press C-x
C-e to see how your XEmacs displays them):
(format "%c %c %c %c %c %c %c %c"
(make-char 'latin-iso8859-1 #xfc)
(make-char 'latin-iso8859-14 #xfc)
(make-char 'latin-iso8859-15 #xfc)
(make-char 'latin-iso8859-2 #xfc)
(make-char 'latin-iso8859-3 #xfc)
(make-char 'latin-iso8859-9 #xfc)
(make-char 'chinese-gb2312 #x28 #x39)
(make-char 'japanese-jisx0212 #x2b #x64))
So you can certainly have a double-width ü at the same time as a
single-width ü, within a single XEmacs :-) .
Now, it’s evident that the first six should be unified, but less so that a
Japanese X11 user will prefer that the system’s ISO 8859-1 font(s) be used
for the character, if the available JISX 0212 fonts are more comprehensive
and aesthetically pleasing than the available ISO 8859-1 fonts, or if the
character is in the middle of a stretch of Japanese text.
I would prefer that we moved to a UCS-with-language-tagging character model
internally, and that charset objects--to describe iso-8859-1, koi8-r,
etc.--have an optional language tag associated with them, observed and
passed up to XEmacs as extent information, when coding systems use those
charset objects to decode text. (The iso-8859-1 character set would be used
both when an iso-2022-8 coding-system hits non-ASCII text, and by some
imaginary Windows-1252 decoder, for example.)
For JIS kana and kanji sets, that language tag would always be “ja,” which
would tell redisplay to use fonts for Han characters read using those
character sets, that are appropriate for Japan. For Cyrillic, the Serbian
language environment would associate a “sb” language tag with the available
Cyrillic character sets, so redisplay can choose the Serbian variant of
those italic (I believe) characters that are treated differently there
compared to usage in the rest of the Cyrillic-using world.
The various language environments would also set up language tags for
various stretches of the UCS code space, to be used by default for UTF
encodings.
Anyway, that’s talk. Implementing it is something else.
--
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
9:01 p.m.
New subject: German umlauts shown as double width when (set-language-environment "Japanese")
Aidan Kehoe <kehoea(a)parhasard.net> さんは書きました:
Ar an naoú lá déag de mí Eanair, scríobh Mike FABIAN:
> It is probably not possible to handle U+00B1 as double width in XEmacs
> and handle German Umlauts as single width at the same time.
“Handle” is a bit ambiguous there. All the following characters are distinct
within XEmacs, but identical in Unicode (select the expression and press C-x
C-e to see how your XEmacs displays them):
(format "%c %c %c %c %c %c %c %c"
(make-char 'latin-iso8859-1 #xfc)
(make-char 'latin-iso8859-14 #xfc)
(make-char 'latin-iso8859-15 #xfc)
(make-char 'latin-iso8859-2 #xfc)
(make-char 'latin-iso8859-3 #xfc)
(make-char 'latin-iso8859-9 #xfc)
(make-char 'chinese-gb2312 #x28 #x39)
(make-char 'japanese-jisx0212 #x2b #x64))
So you can certainly have a double-width ü at the same time as a
single-width ü, within a single XEmacs :-) .
Yes, I know. Of course I already noticed. This causes *very* strange
effects. Before I forced all German Umlauts to single width using
'set-language-unicode-precedence-list' as you kindly explained to me,
I had the following strange behavior:
- an 'ü' typed via the X11 Compose mechanism was inserted as single
width
- an 'ü' typed via XIM using SCIM as the XIM server and
selecting M17N-t-latn-pre as the input method was inserted as
double width.
On top of that of course it often happens that People have various
kinds of 'ü' in a buffer, some read from a file and some just typed
via whatever input method which happens to insert another variant of
'ü'. and when searching for 'ü' with C-s only some of them are
matched, although they may be displayed with the same font and are
visually indistinguishable.
Now, it’s evident that the first six should be unified,
YES!
but less so that a Japanese X11 user will prefer that the system’s
ISO 8859-1 font(s) be used for the character, if the available JISX
0212 fonts are more comprehensive and aesthetically pleasing than
the available ISO 8859-1 fonts, or if the character is in the middle
of a stretch of Japanese text.
I don't think so in case of a German 'ü'. Usually 'ü' doesn't
come
alone, usually it is part of a German word. It looks awkward if the ü
and the ß in "Grüße" are double width and the neighboring ASCII
characters are double width.
No such problem with Greek and Russian because for Greek and Russian
all characters *could* be handled as double width. But I think one
gets more aesthetically pleasing results by embedding them as single
width into Japanese text. When writing with a plain text editor
optionally using a single width space at the borders between Japanese
and foreign text. When looking at Japanese printed material, the
foreign words embedded into the Japanese text are usually printed
using a proportional font where the glyphs are much narrower than a
Japanese kanji, i.e. which is much closer to single width than to
double width. When editing a plain text using an editor with a
monospaced font, you are much closer to the appearance of typical
printed Japanese by using single width fonts for the foreign words.
When trying to embed "Grüße" completely as double width into Japanese
plain text edited in XEmacs, one you could achieve that only by using
the double width forms of the English characters (U+FF21 to U+FF5A in
Unicode) and combine these with the 'ü' and 'ß'. If you save such a
file is saved and then displayed with any other program than XEmacs,
one would see single width 'ü' and 'ß' in between the double width
English characters, which is not nice at all.
I think an ü is an ü is an ü and one is already more than enough,
there should be no different variants of ü's.
--
Mike FABIAN <mfabian(a)suse.de> http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
1:19 a.m.
New subject: German umlauts shown as double width when (set-language-environment "Japanese")
>>>> "Aidan" == Aidan Kehoe
<kehoea(a)parhasard.net> writes:
Aidan> Anyway, that’s talk. Implementing it is something else.
It's actually not that hard to do the redisplay parts, I think. We
need to handle extents just to get the faces anyway, so attach a
language tag to the extent (no Plane 14 stuff, thank you, that's wire
protocol).
Then since currently when the font is snuffled out of the face, we get
language/character set information from the X registry (gag me! why am
I saying that so often these days?) the font is just a string. So we
can tag fonts with languages or character sets by using a cons,
checking for CONSP when extracting the font from the face, and if so
using the language/character set information.
The language environment stuff ... I don't think this belongs in the
language environment. This should be constant data; a Japanese
environment should not tell me that my Arphic fonts are for Devanagari!
--
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.
7250
days inactive
7251
days old
2 comments
3 participants
participants (3)
-
Aidan Kehoe -
Mike FABIAN -
Stephen J. Turnbull