I would like to describe in this particular case, i.e., a terminal
and or terminal emulator that has only 80 columns and a CUI application
wants to display a fullwidth (or, double width) CJK character at
the 80th column, what Solaris terminal emulators (shelltool, cmdtool,
dtterm) and vi(1) and some other CUI utilities are doing just as a possible
reference case:
- The vi(1) displays a tilde (0x7e) character at the 80th column to indicate
that there has been a end-of-line wrapping and display the
CJK character at the 1st column of the next row. The CJK character still
though belongs to the line and the tilde character is only a visual cue and
so it's not in the editor's buffer. I placed a window snapshot in TIFF at
the following URL:
http://ienup.tripod.com/cjk-vi.tiff
The vi(1), by the way, runs in the raw mode.
- For other kind of simple CUI applications, terminal emulators, esp.,
dtterm, have an option called "End-of-line Wrapping" that you can either
disable or enable; if you enable this option, which is the default,
such charcter will be wrapped at the end of the line as like MS-DOS
and XTerm as Tomohiro described in his email and instead will be shown at
the beginning of the next row/line as like the hiragana character A shown
in the following screen dump:
http://ienup.tripod.com/cjk-eol-wrap.tiff
If disabled, such characters will be displayed kind of like overlapping on
top of previous charactes at the end of the line as you can also see from
the above screen dump.
With regards,
Ienup
] Date: Tue, 30 Jan 2001 18:27:36 +0900
] From: Tomohiro KUBOTA <[EMAIL PROTECTED]>
] Subject: Re: backspace policy (Re: kernel tty patches)
] To: [EMAIL PROTECTED]
] MIME-version: 1.0
] Mail-Reply-To: [EMAIL PROTECTED]
]
] Hi,
]
] At Mon, 29 Jan 2001 20:25:00 +0000 (GMT),
] Robert Brady <[EMAIL PROTECTED]> wrote:
]
] > If it has to display just the the first or second half of a wide-character,
] > U+303F is the right thing to display? Does this apply to Hangul, Kana,
] > and Yi as well as Ideographs? What about the wide punctuation?
]
] There are three reasons for 'half of a wide-character' problems.
]
] (1) printf(79 columns of characters and a doublewidth character);
] (2) move(1,1); printf(a doublewidth character);
] move(1,2); printf(any character);
] (3) move(1,1); printf(a doublewidth character);
] move(1,1); printf(a singlewidth character);
]
] I have been using doublewidth-enabled terminals for long years (mainly
] MS-DOS, kterm, and rxvt). In general, it sucks for these cases. At
] worst, all following characters were broken. Though I didn't read the
] source codes for them, I think these terminals don't pay attention to
] such cases. (MS-DOS breaks a line before a doublewidth character in
] case of (1) to avoid 'half-character problem'. I know XTerm already
] has the same algorithm. Excellent. XTerm is better than even Kterm
] or Rxvt in this point.)
]
] The main cause for (2) and (3) is text-based window-oriented softwares.
] The edge of a window can destroy doublewidth character. I think window
] libraries should be responsible to take care of this case. (The erasure
] of the window and resume of the 'under' window cannot be managed well by
] the terminal.) Thus it is application softwares' responsibility to
] avoid (2) and (3).
]
]
] I think you are interested in how XTerm should be implemented.
] However, I feel the recent XTerm (150-23-k5) is now usable for CJK
] people even without 'proper' half-character handling. It would be a
] big news when the XTerm will be released, since CJK people could not
] use XTerm at all so far. (In other words, this XTerm will be regarded
] as the initial release for CJK people.) I am sure a certain amount of
] people will want ISO-2022 support (as Kterm and Rxvt do) [1] but I think
] it is important XTerm (150-23-k5) is usable anyway. Thus, I think you
] may leave half-character problems for futher discussion while we should
] release XTerm with locale-sensibility ASAP. (Well, we need to integrate
] my patch and selection patch.)
]
] [1] I posted a message to Debian JP Developers Mailing List that
] XTerm will support locale encodings and we are now developping it.
] Then I received a mail to ask whether it will support ISO-2022,
] from a developer who is involved into an internationalization
] project of a text-based web browser.
] Theoretically, ISO-2022 can co-exist with almost other encodings
] such as ISO-8859-*, EUC-*, UTF-8, Shift_JIS, and so on because
] these encodings don't include ISO-2022's escape sequences.
] Thus, theoretically it is possible that XTerm support ISO-2022
] without damaging 8bit/UTF-8/locale encodings. Though I would
] be glad if XTerm would support ISO-2022, I know it need a large
] amount of labor and none of us (including me) are brave enough
] to try this work...
]
] ---
] Tomohiro KUBOTA <[EMAIL PROTECTED]>
] http://surfchem0.riken.go.jp/~kubota/
] "Introduction to I18N"
] http://www.debian.org/doc/manuals/intro-i18n/
] -
] Linux-UTF8: i18n of Linux on all levels
] Archive: http://mail.nl.linux.org/lists/
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
