Hi Yoshiki

Yoshiki.Ohshima at acm.org wrote:
> > > > > * TrueType text style
>   All I can say is that I *would* imagine that the SqC would wanted it
> to be a part of core image (but maybe saying this is not fair).
> 
>   I see some compatibility issue can happen if someone wants to
> "refactor" the methods/classes around it.  Let's say StrikeFont
> class>>fromUser: because the method should be at
> AbstractFont>>fromUser:.  Then how do that person/I make sure the
> existing stuff doesn't break?  (And actually I want to do this
> refactoring, but I'm kind of stuff because of this very reason.)
> 
>   It is easier that packages that change such mid-low level should be
> in base image and you can assure people that it is all system you have
> to make sure your package works in.
[Also referring to Markus' mail - some SM package aren't modular
additions]
I think we're missing one another assumptions, so let me communicate
mine -
I was under the impression that we are talking about a package that adds
a specific capability - to import additional ttf fonts. This sounds like
it should be clean and modular, and not affect anything. But when I look
at the code, it seems that it extends and changes several existing
classes. In this case it sounds like there might be some logical
modifications that might be served and appropriate for inclusion in the
image, and some code that does the ttf import itself that should be a
separate package, and with a well enough defined border to not age too
quickly.

Can someone that actually knows the structure of the package well divide
it along those lines? or explain why that's not possible?

> > > > > * Multilingualization
>   There are ongoing pressure from hundreds of, if not thousands of,
> people who wants to have a merged version of Squeak.  (At least
> Squeakland version.)
Ok...

> > Andreas, ignoring the details for a moment. Are you saying that
> > Yoshiki's work is more-or-less complete support for multiple languages,
> > missing mostly additional scripts that can be plugged in? If so, that's
> > news to me. Nobody, certainly not Yoshiki, has suggested it is that.
> > It's on SM as an Alpha package. Anyone can see that it's had lots of
> > thought put into it (I've read the design documents), but that's not
> > enough.
> 
>   Think about this way.  It is (almost) transparent for "English"
> users.  It may break some low-level stuff, but not much if you stick
> to the <= 127 chars.  (It can impose some headache for the users of
> right-half of latin1, though) So, incorporating this doesn't harm the
> general user/developer experience.
> 
>   Adding the support for script is not as easy as "pluggin' in" at
> this stage.  However, we can keep improving this as most of users
> doesn't aware of change.

In short, you do think it's ready for inclusion. Ok, that's good news.
Are there parts of the code that you think are not ready for inclusion
(don't yet quite work, are maybe more complicated than needed...)?
remember maintaining stuff in the image is slower that making changes to
your package on SM...

> > > These _must_ be
> > > present in the base image (if only for being able to leave the option for
> > > other scripts without going through endless hoops). 
> > You seem to be saying that someone interested in multlilingualization of
> > Squeak to the extent that he's willing to do the work needed to add a
> > script could be scared away by the requirement to load a package from
> > SM. I find that statement hard to believe.
> 
>   If it is in the core, the developers of future additions can have a
> mind set that a String/Character is not always 8-bit wide in Squeak.
> That will make the imaginary additional packages easier to be used by
> the other people.  (It is more or less about not comparing characters
> by #== or such little things.)
Andreas seemed to be arguing that it is *useless* on SM. This is not an
argument to that effect (do note that I started this discussion already
very convinced that some multilingual support should eventually be in
the image).

> #   One thing I'm thinking is that I'm going to add a third
> # sources/changes file for transition phase.  Is this a reason for
> # adding/not adding m17n to the core image?
This is the sort of complication I would be somewhat wary of...

> > Someone else adding another script, in a package with Yoshiki package as
> > prerequisite, would sound like a good reason to think about adding it to
> > the image. If someone requested it ;-)
>   Sorry, but I didn't quite understand what you mean here, but anyway,
> I don't think it is a good design that the addtional script is another
> "package" (you mean SM package, I suppose.)
What I mean is that if someone else adds another script, we can get a
perspective from another user of the design about how well it handled
his changes. I think for Squeak long term viability, we should make sure
the code that goes into it is not only comfortable to it's own creator.
It appears to me SqueakMap is a good enough solution to support someone
doing that (even if the script then gets merged into the base
multilingualization package).

Thank you Yoshiki.

Daniel