Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Don't shoot the idea because the implementation is bad. You might like to look at Tim Bray's On the Goodness of Unicode [tbray.org].

    -Dom

    • When Pudge wrote: > I had to deal with stilly UnicodeMapping junk. It's quite annoying, > really. The fork name is type UniChar, and to get a pascal string into > UniChar I need to populate a UnicodeMappingPtr with the encoding > from (kTextEncodingISOLatin1) and to > (kTextEncodingUnicodeDefault), and then call CreateTextUnicodeInfo > to get the mapping, and then ConvertFromPStringToUnicode. It's > really really annoying. he's really annoyed, not at the implementation of Unicode, but at the current state of things without it. First off, he has no idea where he is starting (his incorrect guess is kTextEncodingISOLatin1), then he has the long path home (to Unicode text) which is long precisely because the system to get him to Unicode can get him there from just about anywhere, including Japanese text (in any of several encodings), Arabic text, and English text in DOS, Windows, or classic Mac OS format. In this case he wants kTextEncodingMacRoman, which is for filenames stored in the MacOS filesystem in US English and most western European languages. But this value ought to be read from somewhere, in general, or his solution will fail in Japan and elsewhere. Hmm. I'll try to be clearer in email on the MacPerl list... -Randy