The alternative is fixing the lookup scheme currently used in TTCFont. 
E.g., for TTCFont all you need is to have a mapping from color to 256 
element weak array and use that for lookup. Something like here:

TTCFont>>formOf: char
	| f assoc code |
	char charCode > 255
		ifTrue: [^ self fallbackFont formOf: char].

	cache := colorToCacheMap at: foreGroundColor
		ifAbsentPut:[WeakArray new: 256]

	"... etc ..."

Then all you need to do is some suitable flushing (say on system 
shutdown) and you're done. (if you want to be *really* clever you also 
cache the last cache so that you can avoid the colorToCacheMap lookup 
for the common case of non-changing colors etc)

Cheers,
   - Andreas

Yoshiki Ohshima wrote:
>   Andreas,
> 
>> BTW, if you're looking at TTFs again, the one thing you might want to 
>> consider is to fix glyph color caching. Currently, the worst thing you 
>> can do is to change colors. Say, when using syntax highlighting with 
>> TTFs. Each time the color changes two bad things happen: First, we 
>> recompute the glyph from scratch which is expensive, and second we fill 
>> up the glyph cache with the same glyphs in different colors and 
>> therefore throwing out previous "good" entries which means more 
>> computation when that glyph needs to be displayed. I'll bet that fixing 
>> glyph color caching would allow you dramatically reduce the glyph cache 
>> size and simply ignore the whole notification on full GC issue.
> 
>   Yeah, a new BB combination rule that takes 8-bit (or 4 bit) form for
> grayscale, and halftone (or colormap) for color and do the alpha
> blending would be convenient.  I think it's been written a few times
> by different people, but never gets in the mainstream VM.
> 
> -- Yoshiki
> 
>