2010/7/28 Asmus Freytag <asm...@ix.netcom.com> > On 7/28/2010 9:30 AM, André Szabolcs Szelp wrote: > >> You really all say, that general property Sk (DOT ABOVE) rather than Po >> (FULL STOP, COMMA, MIDDLE DOT) (compared with all other decimal point >> characters) can not cause any problems ever in certain algorithms? >> > No, we say that this is equivalent to a decimal comma - it's the same as > regular comma, and well-designed algorithms can tell the difference. > > Distinguishing identically looking punctuation marks by their function in > text on the level of character encoding is not something that has proven > workable. >
Well, I have replied Ken Whistler privately on a question of his, however, in the particular case I'm trying to digitalize, comma is used as millions-separator, period as thousands separator, and high dot as decimal separator. (formally: #,###.###˙##(###...) ) (I can post the example if necessary). Seeing a number encoded as 1.000 — even knowing this locale!! — you cannot tell whether its "thousand" or "one" with explicit post-decimal zeros, IF you encode both the period and the high dot as FULL STOP. This poses a problem for _any_ contextual alternates-based approach in display as well. So in this case, actually, I think its well arguable, that encoding the decimal point with FULL STOP and treating it as a glyphtic variant is not viable. /Szabolcs
