I'm sorry, i was somehow talking to both of you... Is there any possibility of adding unicode support for StrikeFonts? The complication with international input (mapping or keyboard) was with Freetype (a bit slowish, but in other aspects almost perfect). Viktor ______________________________________________________________
Od: juan@jvuletich.org Komu: gilrandir@centrum.cz Datum: 04.05.2007 03:25 Předmět: Re: Font rendering strategy
Hi Viktor,
I believe StrikeFonts support only 8 bit ASCII. So, using DejaVu with
them doesn't have any advantage. And you can very easily import any font you like.
But I guess you really need Andy's work (FreeType). And with it, you can
load any font you have available.
Cheers, Juan Vuletich
gilrandir@centrum.cz escribió:
Hi, i'd like to appeal to all the font developers - if it's possible,
could you base your great work on the DejaVu font family? These are a Bitstream Vera derivative, so the licensing should't be a problem, but with a lot of completed (and some ongoing) work on non-latin1 charsets - it might not seem like a big issue to you, but the complete lack/brokenness of international support holds a lot of people from using Squeak at all - and i must admit the font machinery in squeak is too complex for me, so i'm one of them in the present time.
With the current FreeType fonts, Squeak is able to load the DejaVu
fontsets and display at least the Czech (Latin-2) charset correctly (but the character mapping or input conversion on Win is somehow broken, so i can input them only with a Czech keyboard hack active).
Thanks to your work it seems to me Squeak is approaching some general
usefullnes eventually :)
Viktor
From: Juan Vuletich <juan <at> jvuletich.org>
Subject: Re: Font rendering strategy Newsgroups: gmane.comp.lang.smalltalk.squeak.general Date: 2007-04-29 16:21:48 GMT (3 days, 20 hours and 50 minutes ago)
That would be great. BTW, I'm working on a small set of fonts free of
any legal issues, based on Bitstream Vera, Komika and may be others, >>
after a suggestion by Diego. I'm pretty sure they could be part of the >> official release without any legal concern. The Bitstream license >> explicitly allows derived works.
Cheers, Juan Vuletich
> [......]
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.
squeak-dev@lists.squeakfoundation.org