2011/9/28 Ken Whistler <[email protected]>: > 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.
