Font rendering strategy

sig siguctua at gmail.com
Sat May 5 18:23:13 UTC 2007


I propose to expand a Font<->BitBlt protocol.
Currently it uses a BitBlt>>installStrikeFont .. and BitBlt>>installTTCFont
to let BitBlt port prepare for font rendering.
I propose to add following methods:
Font sends:
BitBlt>>canCacheGlyphs
and if it returns True, then sends:

BitBlt>>cacheChars: IdentityDictionary (Char -> GlyphInfo) forFont: aFont

instead of installStrikeFont or installTTCFont.
This will give opportunity for bitblt/graphport to implement own
caching schemes and free font from implementing own cache.

And, yes the better way to let Canvas, instead of BitBlt, to interact
with Font. This is more convenient (as for me). It can choose then how
to prepare glyphs for its needs consulting own demands, like target
surface depth, maximum cache size e.t.c.

And giving an info using per-characted basis (in IdentiryDictionary)
is to avoid ascii/unicode issues.



More information about the Squeak-dev mailing list