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 mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
