I read, somewhere, that certain code point ranges had been allocated properties (such as LTR/RTL) in the Unicode tables even though some of them had not yet had characters defined for them. Possibly someone can penetrate the vagueness of this memory and confirm or deny?
If this is the case, have U+035D - U+035F already been assigned the "COMBINING" property?
If I have got it wrong... perhaps something like this *should* be the case? Not for the cleverer properties (LTR, punctuation, numeric); but for something as basic as "should a user be allowed to position the cursor between this character and the previous one?", a generous allowance of code points *now* would let current software work tolerably well with future Unicode revisions, without revision.
At 18:16 12/08/02 -0700, James Kass wrote:
>
>Kenneth Whistler wrote,
>
>> Please note that both the UTC and WG2 have approved a new set
>> of combining double accents:
>>
>> U+035D COMBINING DOUBLE BREVE
>> U+035E COMBINING DOUBLE MACRON
>> U+035F COMBINING DOUBLE LOW LINE
>>
>> <snip>
>>
>> Now, the question is, how long will it take for the fonts and
>> browsers to catch up on those forms, as well??
>>
>
>The other double combiner marks already work fairly well in default
>position in existing browsers. These ought to work right out-of-the-
>box, once fonts include glyphs.
>
>Is it safe to include glyphs for the above referenced characters now?
>
>Best regards,
>
>James Kass.
>
>
>
>
>
This archive was generated by hypermail 2.1.2 : Wed Aug 14 2002 - 01:55:43 EDT