Re: XTerm char-width handling

[Otfried Cheong <otfried@cs.ust.hk>]

 > GOTO Masanori wrote on 1999-10-09 16:20 UTC:
 > > > For reasons of simplicity, I think I'd prefer a strictly cell-based
 > > > cursor control concept. If half a double-cell character gets overwritten
 > > > by text that follows a cursor repositioning, then the other half can be
 > > > substituted with some default character such as space. This seems to me
 > > > to be both most easy to understand and most easy to implement.
 > > 
 > > In such a situation, other half character vanishes.
 > > If the other half is substituted with other characters,
 > > almost users are maybe embarassed.
 > 
 > With "vanishes", I assume you mean "substituted with a SPACE
 > character".

I think he means that the WHOLE double-cell character disappears and
is replaced by the single-cell character (the remainder of the line
shifting to the left).  This of course is the observed behaviour of
any Japanese aware application (like Japanese vi), but as far as I can
see, it is the applications responsibility to implement this.

The behaviour of double-cell able xterm's (Japanese kterm, Chinese
cxterm, Korean hanterm) is motivated by the fact that in EUC encoding,
double-cell equals double-byte.  The two cells of a double-cell
character are identified with the two bytes of the character encoding.
Cursor movement and addressing is though of as being BYTE BASED, not
character based.  In other words, the cursor movements behave EXACTLY
as if Xterm was NOT double-cell aware at all!  Going to col 20 will
move to the 20th byte in the row, regardless of whether there are any
double-cell characters in that row.

It is thus possible to address either half of a double-byte
char. Overwriting it with a half-width char will simply leave the
other half intact (that is, showing half of a double-width glyph!), at
least on Hanterm.

The only difference is that when the cursor is on a double-cell
character, the cursor appears twice as wide, and covers the whole
character.  When the cursor is on the second byte of a double-cell
character, a visual indication is shown (in Hanterm, the second half
is underlined), to show that you are using a non-compliant application
and that editing at this point will lead to disaster.

You may want to play with Hanterm, the Korean version of xterm, which
can actually already understand UTF-8, but only renders ASCII and
Korean, using two fonts.  The development site is
"http://elf.kaist.ac.kr/hanterm/", there is an English manual at
"http://elf.kaist.ac.kr/hanterm/hanterm-3.1.html" (which unfortunately
isn't very complete).

If you want to try it, you'll need "hanterm-3.1.3.tar.gz" and
"hanterm-font*" from "http://elf.kaist.ac.kr/hanterm/pub/".  The
README.0 with installation instructions is in English (basically, you
type "xmkmf" and "make"---it compiles out of the box under Linux).

From the rather large font download, you only need
"10-6-6/johabshg16.bdf". Install it as usual (don't use the Makefile).
Then add this to your  X resources:

Hanterm*hangulFont: -KAIST-Gothic-Medium-R-Normal--16-160-75-75-C-160-JOHABSH-1
Hanterm*hangulCode: 2

(The second line sets hanterm to UTF-8 mode.)

Most of the README's are in Korean (encoded in KSC code), so you have
some material to play with.  Set "hangulCode" to 0 to view them (or
convert them to UTF-8 with "uniconv -I EUC_KR").

Otfried


-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/