From: André Szabolcs Szelp (firstname.lastname@example.org)
Date: Thu Jul 29 2010 - 03:10:46 CDT
2010/7/28 Asmus Freytag <email@example.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
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
(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
This archive was generated by hypermail 2.1.5 : Thu Jul 29 2010 - 03:12:00 CDT