On Dec 30, 2007, at 1:28 AM, Andreas Raab wrote:
Oh, interesting. That reminds me of the fix that I needed for Windows, let me see... yes, here it is: LanguageEnvironment class>>defaultFileNameConverter needs to be fixed since it is (wrongly) guessing the file name encoding based on the currently active locale (which makes no sense btw, since the locale doesn't mean Jack for file name encodings). Hm ... lemme try this ... ah, interesting. It appears that I can make the Umlauts work on Unix correctly if and only if:
- I fix the above method to return UTF8TextConverter in every case
[*1]
- I use -pathenc MacRoman -textenc MacRoman
Which makes no sense to me since neither the path nor the text encoding is MacRoman but it appears to work. Huh?
Careful now is that
ΓΌ 0x9F in macroman or 0x000000FC in utf-32
which is coming back from the VM, then what does the LanguageEnvironment class>>defaultFileNameConverter do and which FONT and character set does that font think it lives in? Since the hex value might not have proper representation if you use a non-unicode proper font after converting from something to unicode....
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================