Juan Vuletich wrote:
> - The  memory consumption estimation you made was with the form that is 
> used to build the fonts. The forms actually stored in the fonts are 
> smaller. The fonts I included go from 1293 * 11 to 2917 * 33.

If we average this (is that fair?) it would come out to:

   2100 "width" * 22 "height" * 4 "depth" * 5 "fonts" * 5 "sizes" * 32 
"derived"

=> 147,840,000

> - My code is just a small fix to StrikeFonts. As such, I think it 
> belongs in any official release.

Uhm, no, not really. It's a new feature not a fix. As such, it should be 
treated with some caution. I'm not saying that it can't be included but 
there are some aspects about it that make me feel very uneasy (for 
example the whole kadoodle in Grafport - I'm virtually certain that 
there will be situations where this is wrong).

As a matter of fact I'd probably vote for leaving StrikeFont completely 
alone and introduce a new font subclass for these guys. It makes clear 
where the assumptions are and the extension points for fonts are by now 
defined well-enough that these fonts could be one loadable option.

> - There are four (that I know) advanced approach to fonts for Squeak: 
> TTCFont, FreeType, Cairo / Rome and Pango. It makes sense to me to 
> include StrikeFonts (including my 32bit fix) in a basic official image, 
> with a really small set of fonts. Then the developer can choose an 
> advanced font package if needed, taking into account that TTCFont needs 
> way more memory than 32 bit StrikeFonts (due to color glyph cache) and 
> that the other options need specific plugins.

It makes more sense to me if your fonts are one of the loadable options 
from Squeakmap. Then people can decide whether they want one, the other, 
or both.

Cheers,
   - Andreas