Craig,

> 	Thanks!
> 
> 	After trying it, I'm wondering if you have any particular optimizations
> planned. On my machine (550 MHz), typing speed and menu performance are
> noticeably decreased (using 13-point Verdana). Are there still some
> relatively easy speedups possible?

  You're using it for code pane(s) with some hundreds of characters in
it?  Yes, it can be slow.  The purpose of mine was pretty much for the
Presentation slides where typical slide only has dozens of characters.

  Regarding the optimization, I can suggest a few things:

  * First of all, if you don't use any fancy background colors,

       TTFontReader>>installTTF:asTextStyle:sizes:

    should be good enough.  For a single colored background, you don't
    have to worry about the anti-alias fringe of pre-rendered bitmaps
    with alpha channel.

  * I was thinking to render the glyphs on 32 bit form and draw them
    onto the destForm with combination rule=24.  But this only works
    when the destForm is 32 bit depth as well.  I was trying this
    approach, but didn't get to a point where I'm happy with the
    result for some reason...  If I remember correctly, it was related
    to the black/transparent pixels (Balloon engine renders black as
    16rFF000000, instead of 16rFF000001 and because it is 32 bit form,
    I can't map colors easily) or something like that.  It is worth to
    investigate again.  Anyway, I even wrote the simple LRU bitmap
    font cache handling mechanism for the multi-octet character set.

  * It may be possible to store the "cached" bitmaps as 8-bit
    grayscale, map the grays to the alpha value and render them.  But
    still the restriction for the destForm applys.

  * The minor point is that the glyphs are stored upside down and it
    is flipped every time.  It wouldn't save too much, but you can
    flip the all glyphs by calling #flipAroundY beforehand.

  As you know, it is mostly about Andreas' code, so let's wait for his
opinion:-)

-- Yoshiki