Re: EXR layer naming conventions

[email protected] writes:

> "Jim Hourihan" <[email protected]> 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

_______________________________________________
Openexr-user mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/openexr-user

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFGhfSl6FFf/c4veGgRAv3HAJ0WMt6OcLgRxdw36wEJDy0nsLXhAwCgiHPe
V8b+8dw8c3GRaLepMlIc4wg=
=9b64
-----END PGP SIGNATURE-----