Re: [Openexr-user] EXR layer naming conventions

[Drew Hess]

address@hidden writes:

> "Jim Hourihan" <address@hidden> wrote:
>> 
>> This is what I was hoping to avoid in my code but cannot. Obviously  
>> if you throw non-english languages possibly represented as UTF-8 or  
>> possibly transliterated to ASCII in the mix you've got a lot of  
>> permutations to deal with.
>
> Readers could be flexible and also recognize lowercase or full words
> for "<channel>" (e.g. "red") or possibly other cases, 


What about "rouge", or "rojo", or "hong", or 赤 ?


> but wouldn't be required to in order to be compliant. Do you think
> anything about a system like that would be unfriendly in regards to
> usage of UTF-8?


As long as you're just comparing strings for equality, any
ISO-compliant C++ std::string implementation can handle UTF-8
encodings.  However, once you introduce case-insensitive comparisons
on UTF-8 strings, you need a proper UTF-8 string facility, which ISO
C++ (and OpenEXR) lacks.  Then there's the whole issue of regexps,
which would be really useful in the presence of layers (e.g., "*.r"),
but get a lot tougher (and slower) when required to support UTF-8
encodings.

I think both UTF-8 and flexible channel names are important issues.
Unfortunately, support for one complicates support for the other.

d

pgpUBfZKFkP9V.pgp
Description: PGP signature