Re: [Openexr-devel] UNICODE support in openexr file I/O

[Drew Hess]

Bob Friesenhahn <address@hidden> writes:

> This is all good, but there is one sticky issue.  If UTF-8 is now
> stored in OpenEXR files, then OpenEXR may return a UTF-8 string to an
> application which is not designed for UTF-8 (e.g. traditional "Unix"
> application) and the application may misbehave.  Is this a possible
> scenario?  If this is a possible scenario, then perhaps new interfaces
> should be added to support UTF-8, and the legacy interfaces should
> behave as closely as possible to before (by transforming to the native
> character set if possible).


That's a good point, but on the other hand, that just sounds like a
bug in the application.  It's similar to the recently-discussed
problem with some applications ignoring the display window: that, too,
is an example of an application misbehaving, and all we can really say
is, "Don't do that."

We should at least state in the documentation that storing UTF-8
strings in attributes is possible and that the application should be
prepared for this if you need to deal with files that were created by
third parties.  

We should also probably state (and perhaps enforce?) that attribute
*names* should be encoded as US ASCII, not because we're xenophobes,
but simply in the interest of maximum compatibility.  (The Ogg spec
for tags in Ogg multimedia files basically makes the same assertion
for the same reason.)  That way, you can at least be sure that you can
parse attribute names correctly even if your application is not
internationalized.

d