Re: XTerm char-width handling

[Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk>]

PILCH Hartmut wrote on 1999-10-09 08:48 UTC:
> I still have one little big problem with my CJK texts, for which
> Markus Kuhn already suggested the solution elsewhere a month ago:
>
> > Xterms needs to be able to load two fonts, one for half-width
> > and one for full-width (e.g., 9x18 and 18x18). The following function
> > should decide, which Unicode character should be normal or wide:

So far, xterm had a fixed 1 character = 1 cell relationship. So when you
asked xterm to position the cursor to the m-th line and the n-th column,
it would always jump to the n-th character in line m.

When characters can now be either 1 or 2 cells wide, what would be the
preferred semantics for the cursor control sequences? Should they
position the cursor on the n-th cell or on the n-th character in a line?

I think, I'd prefer to keep cursor motions in cell coordinates and not
in character coordinates. That means, outputting a Han character puts
the cursor on the same coordinates as outputting two Latin characters.

Is this also how kterm handled this so far? How about the Plan9 terminal
emulator?

Should backspace move back the cursor by one or by two columns, if the
character left of the cursor is a CJK double-cell character?

Is there already some well-established existing practice on how to
interpret VT100 cursor control commands in the context of double-cell
characters, or is it up to us to set the new standard here?

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.

Only backspace might be an exception and should probably work on
characters, not on cells (i.e., go two cells to the left if the two
cells to the left are occupied by a single character), to minimize the
changes necessary to trivial editors such as the line editor in the
Linux kernel tty driver.

The whole cursor control question will come up again, when we start
thinking about really advanced stuff such as combining characters and
ligature substitutions, but these issues are much more tricky and
probably much less urgent than CJK wide-chars at the moment.

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

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