2009/9/6 Yoshiki Ohshima <yoshiki at vpri.org>:
> At Wed, 02 Sep 2009 21:58:04 -0700,
> Andreas Raab wrote:
>>
>> >> * LanguageEnvironment converters: Is there any reason to assume that we
>> >> will ever need to support any encodings other than UTF8/Unicode for the
>> >> VM/image interface? Should we just get rid of all of these different
>> >> converter methods and use the UTF8/Unicode conversions directly, i.e.,
>> >> instead of:
>> >>
>> >>    converter := LanguageEnvironment defaultFileNameConverter.
>> >>    squeakPathName := vmPathString convertFromWithConverter: converter.
>> >>
>> >> the code becomes:
>> >>
>> >>    squeakPathName := vmPathString utf8ToSqueak.
>> >
>> >   For file names, in general, it is ok by now.
>> >
>> > The complication is reading the file names in a zip file.  The name
>> > interpretation has to be special.  The zip files being created and had
>> > been created use Shift-JIS for the archive members' names (I wonder it
>> > is 8859-1 in Western Europe still?).  The #defaultSystemConverter
>> > variant should stay for this purpose.
>>
>> Correct me if I'm wrong, but the #defaultSystemConverter doesn't seem to
>> be used for this. From what I can see in a trunk image, the only
>> reference is in ZipArchiveMember>>refreshLocalFileHeaderTo: using
>> asVmPathName which on a current UTF-8 enabled VM would always use UTF-8
>> anyway. Is this currently broken?
>
>  If that is the case, probably.  I'll try to check it later.
>
>> >> * Converter classes: If the answer to the previous question is that we
>> >> use UTF8/Unicode consistently, is there any reason whatsoever to keep
>> >> the clipboard or keyboard interpreter classes? (we're talking a *lot* of
>> >> classes here; keyboard interpreter has 15 subclasses; clipboard
>> >> interpreter 12 etc).
>> >
>> >   Only reason would be to manage the language tag for some CJK language.
>>
>> Could we fold this into the UTF8 converter? I.e., if the environment is
>> not language-neutral, insert the appropriate language tag?
>
>  It can be a feature of UTF-8 converter (Phillipe wouldn't like it,
> probably though).

Indeed he doesn't. But he uses a modified fast-path from Andreas anyway.

Cheers
Philippe