From: Kent Karlsson (kent.karlsson14@telia.com)
Date: Wed Jul 28 2010 - 10:56:02 CDT
Den 2010-07-28 17.09, skrev "Jukka K. Korpela" <jkorpela@cs.tut.fi>:
> Kent Karlsson wrote:
>
>> And the Nameslist says:
>> 002E FULL STOP
>> = period, dot, decimal point
>> * may be rendered as a raised decimal point in old style numbers
>
> Right, I remembered there is such a comment somewhere but did not remember
> where.
>
>> However, I think that is a bad idea: firstly the digits here aren't
>> necessarily "old style" (indeed, André wrote "lining", i.e. NOT
>> old style). And even if they are old style, it seems to me to be a
>> bad idea to make this a contextual rendering change for FULL STOP
>> (and it also says "may" not "shall" so there is no way of knowing
>> which rendering you should get even with old style digits).
>
> I don't think the comment suggests the kind of contextual rendering you seem
> to be thinking. It just says "may", without specifying what controls the
> rendering and restricting raised rendering to old style numbers.
>
> But admittedly, if you wish to use raised dot rendering, you will need
> either some programmed logic that applies such style to FULL STOP in certain
> contexts but not others (and this is nontrivial) or manual work that sets
> the style of each FULL STOP used as decimal point.
That's "contextual rendering", in the general sense. And as Asmus says, I
don't think anyone has implemented any automatic contextual rendering as
hinted in that annotation (and in the chapter text you referenced), nor do
I think anyone should implement that.
>> Better stay with the MIDDLE DOT for the raised decimal dot.
>>
>> Further, I don't see any major problem with using U+02D9 DOT ABOVE
>> for "high dot" in this case.
>
> I see several problems with both approaches. The rendering will depend on
> font and may not be at all suitable for a raised dot. These characters have
> properties different from those of FULL STOP, and you never know what this
> may imply. Software that handles characters by their Unicode properties may
> do unexpected and unsuitable things if some character just "looks adequate"
> but has properties different from those of the character(s) that would be
> semantically (more) correct.
Such as exactly which problems here? If any, those are surely dwarfed
by several orders of magnitude compared to that some locales use "." as
thousands separator and others use it as decimal separator, and some
locales use "," as thousands separator and other use it as decimal
separator.
/kent k
> Jukka
>
>
This archive was generated by hypermail 2.1.5 : Wed Jul 28 2010 - 10:57:14 CDT