I do think you are correct, a more generic (and lower-level solution)
would be more appropriate--and in the locations you've identified.
Presently, I do not yet have the skills to make such a change, as the
mysteries of how Squeak renders to the screen (especially how Morphic
renders to the screen on top of all the BitBlt / Display stuff from
earlier Smalltalks).

One observation: Display>>form doesn't do much work, but
Display>>composeForm does, and (in the case of Morphic) it strangely first
creates a TextMorph of the text, gets an image from that with a depth of
1, then builds a ColorForm on which it draws that image.  Don't know why
all of that work--seems like just one really good rendering on an
appropriately configured form or canvas should have done the trick, but,
as mentioned, I don't yet grok Squeak's rendering architecture.

Yet.


On Thu, 12 Dec 2002 Yoshiki.Ohshima at acm.org wrote:

>   Phil,
>
>   Thank you for the feedback.  I looked at your code.
>
>   TTCFont.class.PH.1.cs looks fine.  I didn't think about the FileList
> action, but it makes sense.  It would be nice for now if there is a
> way to create the true type banner which supports the rotation.  Of
> course, in the future, TTTextStyle should be able to support it.
>
>   I'm wondering if there is a bit more generic solution for the
> ProgressBarMorph.PH.1.cs, such as modifying the logic around
> DisplayText.  Namely, how about if DisplayText>>form returns 32bpp
> forms if the TTCFonts are used, and
> DisplayText>>displayOn:at:clippingBox:rule:fillColor: renders it via a
> temporary created FormCanvas?
>
> -- Yoshiki
>
>