Daniel,

> Yoshiki.Ohshima at acm.org wrote:
> [Snip about TTFonts]
> >   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.
> OK, stupid idea on my part. I've given up on any chance for me to add
> anything coherent to the discussion of this package. I will not object
> if someone else harvests this da^H^H^H package ;-).

  On the other hand, I think I can provide the unload mechanism for
TTF related classes including the existing TTSampleStringMorph.

> > 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.  
> And what if we do include it and it doesn't go anywhere anyway?

  It is a possibility, but it doesn't hurt (too much).  Even if it
exists in the image, a developer can always forget about the detail of
how strings are rendered, etc. and develop his/her application.

  For example, something like Nebraska, which forwards the string
drawing methods on a canvas was made m17n-ready way after we first
released the m17n image.  But it used to work fine as long as there
were no extended characters on the screen.

> I'd like one additional voice saying that it is good enough to be fixed,
> so that if it get's fubared and you're otherwise occupied, we don't find
> ourselves stuck. <whisper>3.3a modules</whisper>.

  3.3a modules was in my mind, too.  But the amount of impact to those
who doesn't want to deal with the new addtion looks pretty different.

  Sorry for my *slow* response.  I'm writing this within not too more
than 12 hours after I've got your post, but this email I'm writing
looks soooo outdated now.

-- Yoshiki