Re: Internationalisation and fonts - a suggestion

[Pete French]

> But that would be *very* wrong.  Conversion to/from character sets needs to
> fail if the conversion is not possible, rather than trying to guess what the
> correct results are.  If we skip unintelligible rubbish while converting, the
> application has no way of telling that there is a problem... we have to fail
> when there is rubbish in the string, so the application can do something
> about the problem.

I just tested this on OSX, and you are right - it does just return nil
when there is garbage in the string. In which case are we to assume that tghe
bug with the opening of files when theres an incorrect strng encoding set
is actually a bug in the open panel - i.e. its not handeling failed
conversions properly ?

> eg. if we have a string containing a single utf16 character occupying 4 
> bytes, and we use the -length and -characterAtIndex: methods, will the string 
> appear to contain two characters or one?

It appears to contain two. Apple doesnt seem to actually support UTF-16 to
any great degree, other than inserting the paired surrogates when necessary.
A unichar is still 16 bits on OSX.

> I'd welcome anyone volunteering to do the coding for that move from us2 
> to utf16

I'm happy to do the coding to make the UTF8 code at least insert the paired
stuff (and still barf on bad sequeneces), plus the conversion the other way.

I wanmt to explore what apple does as regards some of the internal operations
on strings to seeif it supports UTF-16 there (the precomp and decoomp stuff
for example).

-bat.