Convincing a harvester (was on SqF list)
Yoshiki.Ohshima at acm.org
Yoshiki.Ohshima at acm.org
Wed May 7 20:29:10 UTC 2003
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
More information about the Squeak-dev
mailing list
|