Re: [Openexr-devel] UTF-8

[Larry Gritz]

OpenEXR shouldn't have to worry about this nonsense internally.

My vote would be to make libIlmImf continue doing an exact compare (strcmp), 
but put in the docs that the strings are assumed to be UTF-8 and that any apps 
using the library should canonicalize with normalization "C" any channel name 
or attribute strings *before* passing them to the library, and if they don't do 
so, they get what they deserve in terms of false negative string matches.

        -- lg


On Nov 16, 2012, at 8:34 AM, Jim Atkinson wrote:

> 
> On Nov 15, 2012, at 4:12 PM, Florian Kainz <address@hidden> wrote:
> 
>> 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?
> 
> I agree, "foo" is a contrived example.  Also, I guess I misunderstood you 
> since I thought you were suggesting that we normalize *all* strings in the 
> header.  I'm much happier with the suggestion that we normalize all attribute 
> and channel names but no attribute values.
> 
> My main complaint is that it adds a lot of extra complexity, dependencies, 
> and portability issues to an image format library.  The main reason for 
> adding it seems to be that there may be an application that may display a 
> layer name that a user may have difficulty typing in.
> 
> As a monolingual English speaker, I simply don't run into these issues often. 
>  When confronted with a layer named "공룡" or even "grün", I'm forced to cut 
> and paste it or select it in a GUI.  So maybe I don't understand how really 
> pervasive and frustrating these issues are.  But it sure seems like unicode 
> normalization issues should be outside the scope of OpenEXR.
> 
> - Jim
> 

--
Larry Gritz
address@hidden