> http://developer.apple.com/documentation/Java/Conceptual/Java14Development/
> 04-JavaUIToolkits/JavaUIToolkits.html
>
> Font Encoding
>
> The default font encoding in Mac OS X is MacRoman.
[...]
> The default font
> encoding on some other platforms is ISO-Latin-1 or WinLatin-1. These are
> subsets of UTF-8 which means that files or filenames can be turned into
> UTF-8 by just turning a byte into a char.
This is utter nonsense, UTF-8 uses up to six bytes for one character. This
probably rather means that all three mentioned character encodings have ASCII
as common subset or that the encodings can represent a subset of the
characters representable in UTF-8.
> Programs that assume this behavior cause problems in Mac OS X.
Well, that's not unexpected, see above.
> If you do not specify a font encoding explicitly, recognize that:
>
> *
> In the conversion from Unicode to MacRoman you may lose information.
>
> *
> Filenames are not stored on disk in the default font encoding, but
> in UTF-8. Usually this isn’t a problem, since most files are
> handled in Java as |java.io.File|s, though it is good to be aware of.
>
> *
> Although filenames are stored on disk as UTF-8, they are stored
> decomposed. This means certain characters, like e-acute (é) are
> store as two characters, “e”, followed by “´” (acute accent). The
> default HFS+ filesystem of Mac OS X enforces this behavior. SMB
> enforces composed Unicode characters. UFS and NFS do not specify
> whether filenames are stored composed or decomposed, so they can
> do either.
I believe this only relates to encoding of Fonts in Java, which also has its
own internal character encoding. However, it says that the default file name
encoding is UTF-8, which is nice to know (once I finally have my mac...).
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 24 09:11:08 2005