> I agree that a clarification in the text would be better than > a comment in allkeys.txt. But I also think just changing "(in 6429)" > to "(in ISO 6429)" would be enough. > > (Strange as it might seem for list regulars not everyone immediately > makes the right association from this four-digit number. :-)
Ah, I see what the interpretation problem was. Yes, that is a straightforward kind of improvement -- easily enough done. Look for a change the next time the file is updated. (It will not be immediately changed, pending other review comments.) > This is somewhat besides the point, but since you say the file is > machine-generated I wonder about something I found in the draft version > http://www.unicode.org/Public/UCA/7.0.0/allkeys-7.0.0d5.txt > where a comment says > > # Tertiary weight range: 0002..001F (30) > > even though the highest used tertiary weight actually is 001E. > Isn't this comment automatically made? The ranges for primary and secondary weights change with every new repertoire addition to the input, so they are always calculated dynamically. By contrast, the tertiary weight range is hard-coded in the generation, and never changes. If you look at: http://www.unicode.org/reports/tr10/#Tertiary_Weight_Table you can see all those pre-defined, fixed values. It is true that 0x001F is not actually assigned as a tertiary weight for any particular character, but it is internally set aside as a MAX_TERTIARY sentinel value, before the first secondary weight of 0x0020. Note that the tertiary weight 0x0007 is not actually used in the weighting, either (for historical reasons). At any rate, the entire range 0x0002..0x001F is considered fixed and "used" for tertiaries, so that is what is always displayed in the summary printed at the top of allkeys.txt. --Ken _______________________________________________ Unicode mailing list [email protected] http://unicode.org/mailman/listinfo/unicode
