John,

  I would also say that you wouldn't need to have more than MacRoman
UTF-8, and probably "no-conv", even though the Mac OS X API seems to
provide dozens of encodings.

  Also, I don't think the VM doesn't have to compose the composable
Unicode values.  I've got an impression from Hayashi-san that the
native "encoding" of Mac OS X is normalized to decomposed Unicode.
The image should be able to compose those if necessary, and if the
image passes precomposed string, the Mac OS X API should take care of
it.

  Adding those little stuff would be a good step towards making the
main stream Squeak multilingualized, but having the VM that does too
much stuff, and incompatible change at the image level with the m17n
package will definitely hurt.

-- Yoshiki

At Fri, 28 Nov 2003 01:51:52 -0500,
Yoshiki Ohshima wrote:
> 
>   John,
> 
>   Adding those functions may be ok.  I would prefer the IANA encoding
> names over the magic numbers, though.
> 
> > This allows plugins, like the mpeg plugin to accept a file name from  
> > the VM and know what to do
> > with it before issuing the file open by asking the VM what the encoding  
> > is. It also of course allows
> > a programmer the ability to see and choose an encoding to use within  
> > the Image.
> 
>   Having different internal encoding wouldn't be a good idea.  Such
> plugin shouldn't bother to translate the file names passed.
> 
> > What is unclear, but could be defined is how to deal with existing path  
> > information, such as the vmpath
> > once you switch encoding. I suppose you could leave that information in  
> > native platform format and
> > return a converted value  based on the currently chosen encoding.
> 
>   Is the info like VM path used before the image becomes *live* and
> take the control?  Using somewhat native encoding for VM path,
> etc. sounds make sense to me.
> 
> -- Yoshiki