From: Philippe Verdy (email@example.com)
Date: Mon Jan 31 2011 - 10:30:55 CST
Given that the GC property is stabilized, I tend to think that this should
not change. There are probably good reasons why some were initially encoded
as "modifier letters". What really matters is that they are in the "L*"
general category, and the compatibility decomposition type "<sub>" (or in
the same rationale "<sup>") should be a better guide to make a clear
selection of subscripts (and superscripts) of "normal" letters (whose code
point is given, and from which we can say if it's lowercase or uppercase).
May be a new derived property could be computed instead of changing any GC
property, for small and capital subscripts, or small and capital
superscripts variants of normal letters (I have not checked if there were
instances of superscripts and superscripts for uncased letters, or
superscript/supscript letters in mixed case / title case). Such derived
properties could be used in font renderers when those characters are not
mapped in a font and when the superscript/superscript variants can be found.
It would not be difficult to compute this derived property, unless there's
some exception. This requires some verifications.
2011/1/31 Kent Karlsson <firstname.lastname@example.org>
> There are also some Greek ones in the same predicament(?):
> 1D66;GREEK SUBSCRIPT SMALL LETTER BETA;Ll;0;L;<sub> 03B2;;;;N;;;;;
> 1D67;GREEK SUBSCRIPT SMALL LETTER GAMMA;Ll;0;L;<sub> 03B3;;;;N;;;;;
> 1D68;GREEK SUBSCRIPT SMALL LETTER RHO;Ll;0;L;<sub> 03C1;;;;N;;;;;
> 1D69;GREEK SUBSCRIPT SMALL LETTER PHI;Ll;0;L;<sub> 03C6;;;;N;;;;;
> 1D6A;GREEK SUBSCRIPT SMALL LETTER CHI;Ll;0;L;<sub> 03C7;;;;N;;;;;
> /Kent K
This archive was generated by hypermail 2.1.5 : Mon Jan 31 2011 - 10:33:56 CST