Hello,

> > > > * TrueType text style
> [It provides support for beautiful fonts, as an example, you can see
> Diegos look enhancements]
> That wasn't hard, was it? BTW, it's too bad that this isn't the first
> line of the SM packages description... you don't really expect people to
> understand all that technical mumbo jumbo, right Yoshiki? ;-)
> 
> I don't think it should go into the image. Anyone differs?

  Alright.  I changed the package description.  If you (you guys) have
more suggestions for the detailed description part, I'm happy to
change it, too.

  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.

> > > > * Multilingualization
> > > First of all, I agree this eventually affects something that should be
> > > in the base image, and probably care about this more than most, since my
> > > primary language has zero support in current Squeak. And Yoshiki has
> > > gone the extra mile and made it an SM package, so theoretically the
> > > barrier to test it is zero. I don't understand why there's almost no
> > > feedback, the null hypothesis is that nobody cares enough. In which
> > > case, I tend to not want it in the image.
> > 
> > I completely, absolutely, and utterly disagree. This is a strategic issue.
> > The "lack of feedback" as you call it (btw, there _has_ been feedback on
> > Japanese) 
> I wouldn't comment on this triviality, but this isn't the first time I
> get the impression you don't read my posts very carefully. My exact
> words were "almost no feedback". As you can surely see :-)

  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.)

> [It's strategic]
> I do know, ask Yoshiki, or review the list archives - this work might
> not be be on SM if I didn't.

  Your encouragement was great, Daniel.

> 
> 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.

> > 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.)

#   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?

> 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.)

  Thanks,

-- Yoshiki