[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
pgpL7sE6L9oAF.pgp
Description: PGP signature
_______________________________________________ Openexr-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/openexr-user
