[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Openexr-devel] UTF-8
From: |
Florian Kainz |
Subject: |
Re: [Openexr-devel] UTF-8 |
Date: |
Thu, 15 Nov 2012 16:12:35 -0800 |
User-agent: |
Thunderbird 2.0.0.24 (X11/20100428) |
Jim Atkinson wrote:
If the application normalizes all the strings it provides to the library, everything will work. And if the application doesn't
normalize all the strings, everything will still "work". A user may just find that "grün" and
"grün" will be different channel names just like "foo" and "fоо" are.
I don't think the "grün" case is equivalent to "fоо" being spelled with a
Cyrillic o.
"Grün" is a real word. On my keyboard I press the "Ü" key to type the
third letter, but I don't know, and I have no control over, what happens
next. Depending on my application software the third letter may be
represented as 00FC or as 0075 0803. Either way, "grün" is the German
word for "green," and if application software that tells me that "grün"
and "grün" are different words, based on invisible technical details that
are beyond my control, then I'd consider that a bug. I'd guess other
users of the application would agree.
On the other hand, you would have to go out of your way to spell "fоо" with
a Latin f and a Cyrillic о. And most likely you'd only do that to confuse
the reader.
It is true that you might see a word such a "сор" and assume it is English,
when it is in fact the Russian word for "dirt" (pronounced "sor"), but this
situation is kind of rare. The presence of other Russian words would
probably alert you to the ambiguity. Also, there are ways to type either
a Latin "c" or a Russian "с."
Jim, what would be the downside of normalizing attribute and channel names?
Would it prevent you from doing something that you can do now?
I don't buy the slippery slope argument. If we say that attribute names and
channel names must be normalized, but other strings don't have to be, where's
the problem?
Florian
- [Openexr-devel] UTF-8, (continued)
- [Openexr-devel] UTF-8, Hồ Châu, 2012/11/14
- Re: [Openexr-devel] UTF-8, Florian Kainz, 2012/11/14
- Re: [Openexr-devel] UTF-8, David Aguilar, 2012/11/14
- Re: [Openexr-devel] UTF-8, Florian Kainz, 2012/11/14
- Re: [Openexr-devel] UTF-8, David Aguilar, 2012/11/14
- Re: [Openexr-devel] UTF-8, Florian Kainz, 2012/11/15
- Re: [Openexr-devel] UTF-8, David Aguilar, 2012/11/15
- Re: [Openexr-devel] UTF-8, Jim Atkinson, 2012/11/15
- Re: [Openexr-devel] UTF-8, Florian Kainz, 2012/11/15
- Re: [Openexr-devel] UTF-8, Jim Atkinson, 2012/11/15
- Re: [Openexr-devel] UTF-8,
Florian Kainz <=
- Re: [Openexr-devel] UTF-8, Jim Atkinson, 2012/11/16
- Re: [Openexr-devel] UTF-8, Larry Gritz, 2012/11/16
- Re: [Openexr-devel] UTF-8, Britton, Andrew D, 2012/11/16
- Re: [Openexr-devel] UTF-8, Brendan Bolles, 2012/11/15
- Message not available
- Re: [Openexr-devel] UTF-8, Brendan Bolles, 2012/11/15
Re: [Openexr-devel] UTF-8, Lars Borg, 2012/11/13