Re: Noticed improvement in the Code chart link http://www.unicode.org/charts/

2011/9/28 Ken Whistler <kenw_at_sybase.com>:
> It might be most productive for people concerned with this issue to be
> reviewing
> the charts currently in preparation for Version 6.1.0 of the Unicode
> Standard, rather than
> the already published charts from last year. Please see, for example:
>
> http://www.unicode.org/Public/6.1.0/charts/blocks/U0980.pdf

I'd like to have an opinion about why this chart (for example)
describes two code points 09E4 and 09E5 as <reserved>, without
assigning any glyph, but still associating them with other punctuation
signs in another script. Are these positions permanently reserved for
the case where specific danda signs would be later discovered and
encoded specifically in this script ? OR are they really unassigned
and usable for encoding later any other kind of character ?

If there are related characters not found in a block but that can be
found in other blocks, it would probably be smarter to document them
with the "see also" note (the left arrow) at the begining of a
subsection allocated for punctuation signs

Or probably better in an additional "See also" subsection. If we just
look at the graphic chart, these positions are greyed like all other
unallocated positions. but the list can create confusion (and may
incite font developers to map on those positions another copy of the
same glyphs assigned to 0964 and 0965 in the Devanagari script, or
simply, in a Bengali-only font, to assign only the two reserved
positions.

This "See also" subsection should also list (and link?) the other
blocks allocated for the same script (so charts would still need to be
updated if one block is not modified by itself, but a new block is
allocated for the same script).

I wonder if this is a current limitation of the program that generates
those charts (can it create a subsection without any code points in
it, and insert notes just the same way they exist at the begininng of
non-empty subsections like the "Two-part dependant vowel signs" ?) or
if this is needed for compatibility with fonts not mapped with Unicode
but with a legavy 8-bit encoding, with a simple offset to convert the
code positions into code points ?

-- Philippe.
Received on Thu Oct 13 2011 - 11:23:16 CDT