Markus Kuhn:
MK> I think the proposal is now very mature and ready for test
MK> implementations.
Markus, I disagree. I think we most definitely need to think about it
some more.
First of all, your proposal requires unbounded memory on the terminal
emulator. I would like to know what model for the client application
you have in mind: do you expect the client application to preprocess a
string of arbitrary length, and precompute a SCW sequence for it? Is
that realistic?
I remain convinced that if we need SCW at all, we only need it to be a
single shift. I, for one, would have no clean way of fitting such
preprocessing in luit.
More generally, I am wondering whether we need SCW at all. The only
example I have heard is that of double-width Cyrillic in Japanese lo-
cales; I am still not convinced that this is an important application.
Are there any more convincing examples?
If people feel that proper width handling is really important, than I
would like to hear about the alternatives. Is there no existing DEC
sequence with a similar effect? (DECDWL comes to mind, but it only
works on a per-line basis.) Is there no Unicode control character
with a similar effect? If not, is there no Unicode control character
that we can use for that effect? If not, would it not be more sui-
table to register such a character with Unicode, thus enabling proper
handling of widths (absolutely essential, you tell me) in arbitrary
Unicode streams? If not, would it not be better to use a PUA charac-
ter for this purpose?
Regards,
Juliusz
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
