Daniel,

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

  Hmm.  The TrueTypeTextStyle modifies a bit of existing classes, and
uses the existing TrueType related classes such as TTFontDescription,
TTFontReader, and etc.

  The deviding line you mention depends on whether you want to get rid
of those existing TrueType font stuff.

  But, honestly, I don't think that is a great idea to have an image
that contains the classes that represent the read data structure
without having the reader logic itself.

  So, if you want, you could go along this line, with some PlayWithMe
modifications.

# By the way, if someone is encountering the bug of TTTextStyle that
# doesn't let you mix the TTCFont and StrikeFont, put the following
# line into
# GrafPort>>installStrikeFont:foregroundColor:backgroundColor: at the
# appropriate place.
#
# combinationRule = 34 ifTrue: [combinationRule _ Form paint].

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

  Oh, well.  This is a tricky question.  There are many places to be
fixed, such as the way it accesses the so-called "message catalog"
thing (the way it is is crazy), the messy state of co-existing
CharacterScanners and MultiCharacterScanners, etc.  My feeling is that
I'd be embarrased in some code, but at the same time it is not going
anywhere until it is included.  It is stable in that sense you can
fix/modify the code with following stream of change set.

  If "don't yet quite work" is the criteria to judge if it is ready or
not, maybe it is not.  But, I kind of feel that this is not the
optimal criteria.  I might say "it is good enough to be fixed" would
be the one...

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

  The third file can be created only when you want to use the extended
characters.  Three files are the transition, where the .sources and
.changes are in an encoding scheme and the third one is in another.
But, my feeling is that we need to get through this phase anyway.

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

  Hmm, this maybe the strategic thing Andreas was mentioning.  My gut
feeling (I like this phrase:-) is that until it gets into the main
stream, not many people are going to take a look at it seriously.

-- Yoshiki