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

stephane ducasse escribió:
> thanks a lot for the explanation.
> So I have the impression that we could have a selected number of fonts 
> per default
> using the scheme of juan so that we have a nice looking Squeak and 
> your schema to get the
> full access and power. Sounds really promising.
>
> Stef
>
> On 29 avr. 07, at 14:43, Andrew Tween wrote:
>
>> Hi Stef,
>>
>> ----- Original Message -----
>> From: "stephane ducasse" <stephane.ducasse at free.fr>
>> To: "The general-purpose Squeak developers list"
>> <squeak-dev at lists.squeakfoundation.org>
>> Sent: Sunday, April 29, 2007 10:52 AM
>> Subject: Font rendering strategy
>>
>>
>>> Hi guys
>>>
>>> I want to thanks andy and juan for their work!
>>> Now I need your brain and knowledge.
>>> I'm totally ignorant of font problems/challenges but
>>>
>>> How can we get the best of both works?
>>
>> The two approaches are different, and each solves a different set of 
>> problems.
>> What ~I~ want from a font system is...
>>     1. Automatic access to all the fonts in my host OS.
>>     2. The ability to use them at any point size.
>>     3. The ability to render in any colour, on any background 
>> (including a
>> transparent background)
>>     4. Optional support for sub-pixel anti-aliasing, without 
>> compromising points
>> 1, 2 and 3.
>>     5. Unicode support (in my case, not so much for language support, 
>> but rather
>> for access to mathematical symbols)
>>     6. Better support for printing (e.g. scale up a TextMorph's 
>> contents to my
>> printers dpi, and output as a .png)
>>     7. Support for different underline/strikethrough styles (e.g. 
>> text in black,
>> underline in red; jagged underline; double strikethrough)
>>     8. Support for subscript/superscript; raised/lowered text.
>>
>> FreeType solves points 1 and 2, but they could also be solved by 
>> grabbing font
>> info, glyphs, and metrics directly from the OS.
>> Something similar to the Win32 Native Fonts package. (This is 
>> something I would
>> like to do in the future - with the ability to grab 
>> ClearType/sub-pixelled
>> glyphs on Windows, and something similar on Macs).
>>
>> The BitBlt plugin enables 3 & 4.
>>
>> Points 6, 7 & 8,  I haven't done much with.
>> But, for example, I render underline and strikethrough as a separate 
>> BitBlt
>> operation, rather than modifying the glyphs to include
>> underlining/strikethrough. So it should be easier to include 
>> different styles.
>>
>>
>>> What are the exact pros and cons in terms of:
>>> - font
>>
>> My approach gives you access to fonts, without requiring that you 
>> import them.
>> Juan's approach allows you to selectively import fonts, and to 
>> subsequently edit
>> them.
>>
>> My approach allows easy use of any point size.
>>
>> Juan's approach caches the glyphs/metrics in the image, so if the 
>> image is
>> distributed, then the font (file) does not need to exist on the 
>> target machine.
>> My approach deliberately clears any cached glyphs/metrics on image 
>> save so
>> that...
>>     a. there is no danger of violating font licenses by shipping 
>> cached data
>>     b. if the same font exists on the target machine, but is a different
>> version, then the target machine's version wins (Arial on Windows 98 
>> is not
>> necessarily the same as Arial on Vista, or on Mac OS X)
>>
>> I also support kerning and sub-pixel positioning for nice 'WYSIWYG' 
>> text layout.
>>
>>> - size
>>
>> :) Size of what?
>> The image? My approach has more code, but I don't cache 
>> glyphs/metrics in the
>> saved image.
>> VM? My approach requires the FT2Plugin, & the FreeType library on 
>> Windows/Mac.
>>
>>> - memory consumption
>>
>> I have a glyph cache whose maximum memory consumption can be set by 
>> the user
>> through a Preference.
>> The default is 5 MBytes.
>> The FreeType library also has a fixed overhead, plus an overhead per 
>> font that
>> is used (not every font on the host OS, only those that are actually 
>> used within
>> the image).
>> I have tested my stuff on a 7 year old PIII with 64MBytes RAM, and it 
>> runs quite
>> happily.
>>
>> With Juan's approach it will depend upon the number of fonts/point 
>> sizes that
>> are imported into the image.
>>
>>>
>>> It seems that juan work is excellent for OS independence.
>>
>> Yes.
>> Shipping glyphs in the image  is a good way to ensure that they are 
>> available on
>> all platforms.
>> But I am not sure of the legality of that. For monochrome bitmap 
>> glyphs I think
>> it is ok. But when the glyphs have been anti-aliased, or sub-pixel 
>> anti-aliased,
>> I don't know?
>>
>> I take a different approach and revert to using a strike font if any 
>> one of the
>> FT2Plugin, the FreeType library, or a particular font file is absent 
>> from the
>> user's machine. So any image, or project, should still be runnable 
>> and useable
>> on any OS.
>>
>> Cheers,
>> Andy
>>
>>
>>
>
>
>
>
> --No virus found in this incoming message.
> Checked by AVG Free Edition.Version: 7.5.467 / Virus Database: 
> 269.6.2/780 - Release Date: 29/4/2007 06:30 a.m.
>
>