Re: Unicode biwidth fonts

From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Tue Dec 08 1998 - 20:20:05 EST


At 04:20 PM 12/8/98 -0800, Markus Kuhn wrote:

First of all, please reference the TR not the DTR

http://www.unicode.org/unicode/reports/r11.html

>I guess the best convention is to declare the characters of category W
>and F in Unicode Draft Technical Report #11 <http://www.unicode.org/
>unicode/reports/dtr11.html>, i.e. the characters 1100..11F9, 3000..30FE,
>3131..33FE, 4E00..9FA5, AC00..D7A3, E000..E757, F900..FA2D, FE30..FE44,
>FE49..FE52, FE54..FE6B, FF01..FF5E, FFE0..FFE6, to be wide characters
>occopying the space of 2 ASCII characters, and all the remaining Unicode
>characters are as wide as ASCII characters in a monospaced font.

I realize that a single world wide font is restrictive. But following your
convention, could lead to some surprises, as an EA user would expect to see
all the category A characters rendered as double cells as well.
The only 'correct' answer would be to have two fonts, one with A as single
cell and the other with A as double cell and to switch between them
depending on whether you are in EA legacy mode or not.

>What I don't like about the tables in DTR11 is that class X is so large.

class X has been removed

>If there is a single code point free in the middle of a large number of
>W characters, then this code point should be reserved to future W
>characters and should not be listed as unassigned.

Unicode never assigns properties to unassigned code points.

>The distinction
>between narrow and wide characters should be possible efficiently in
>software in an if statement that fits on three lines in C without a
>table lookup. The given intervals should be a bit more generous to
>simplify implementation.

Implementations can simplify anything they want to, since EA Width is
_informative_ at this point.

A./



This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:43 EDT