Juan Vuletich wrote:
> Andreas Raab wrote:
>> 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).
> 
> It is just a fix. Why should StrikeFonts break with more than 1 bpp? 

Because they weren't designed to work with anything but 1bpp. Otherwise 
you might as well ask "Why should the Squeak VM break with Java 
bytecodes? It's just bytecodes after all." A nonsensical argument.

>> 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.
> 
> I don't agree. The "assumption" that StrikeFonts are 1 bpp is not 
> documented. And it doesn't make sense anyway.

Oh, well if you want to make everything in Squeak that's "not 
documented" mean undefined you might as well start over ;-)

>>> - 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.
> 
> I don't see in what they differ from StrikeFonts.

I do.

Cheers,
   - Andreas