Hi, At Mon, 04 Feb 2002 11:40:53 +0000, Markus Kuhn wrote:
> One potential alternative is that, given Unicode 3.2 has just > introduced the notion of variation selectors, we ask the > UTC and WG2 to consider the addition of two special variation > selectors for single-width and double-width selection of glyphs > in the East Asian ambiguous class. Interesting. I have a few comments. 1. The range of characters for which I want to use doublewidth version is not limited to EastAsianAmbiguous class. The list of such characters depend on Unicode <-> local encodings mapping tables and we don't have authorized reference mapping tables. Thus, I cannot show an exact list of such characters. However, if we want to support Japanese mapping tables in http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA which are widely used now, characters in "Width problems" in http://www.debian.or.jp/~kubota/unicode-symbols.html should be supported by your "Width Selector". (I checked Japanese mapping tables only. Checking for Chinese and Korean tables may add characters to the list.) Thus, I think it is a good idea not to limit the range for which "Width Selector" is effective. (Another idea is to change EastAsianWidth definition. However, my proposal to change EastAsianWidth has failed...) 2. I am afraid that your proposal (or proposal to change ISO 6429) may take long time to be realized. It does not mean that it is not a good idea to propose "Width Selector". I mean, we need some temporary solution because this is a practical problem, rather than a standardization problem. 3. I think your proposal is better than your SCW proposal because this proposal is STATELESS, though SCW proposal can be simplified to be stateless. > That would be most easy to > implement with existing font display engines that feature ligature > substitution. That would be a way of allowing applications or > encoding translation filters to have tight control over the > width of a character on a character cell terminal, without > the introduction of new ESC sequences. The a font could easily > contain both narrow (CP437) and wide (JIS) versions of the > U+25xx box drawing characters, etc. I don't think introduction of new 'character' is better than introduction of new ESC sequences. I think they are equivalent. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.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/linux-utf8/
