Font rendering strategy
Locked
 
|
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? What are the exact pros and cons in terms of: - font - size - memory consumption It seems that juan work is excellent for OS independence. Stef |
|
|
stephane ducasse wrote:
> 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? > What are the exact pros and cons in terms of: > - font > - size > - memory consumption > > It seems that juan work is excellent for OS independence. > > Stef > some presentation for others to download and what to make sure the fonts are represented correctly, because you used some special font you can't expect other have on their system. Karl |
Re: Font rendering strategy
|
|
In reply to this post by stephane ducasse
I don't see how the approach of Juan scales to:
- unicode - different fonts - different font sizes - different font styles (bold / italic / bold and italic) But maybe I just misunderstood something. Cheers Philippe 2007/4/29, stephane ducasse <[hidden email]>: > 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? > What are the exact pros and cons in terms of: > - font > - size > - memory consumption > > It seems that juan work is excellent for OS independence. > > Stef > > |
|
|
In reply to this post by stephane ducasse
Hi Stef,
Tim has given good arguments for using StrikeFonts for actual rendering and FreeType for building them, especially on slow machines. On fast machines, FreeType will look better. Cheers, Juan Vuletich stephane ducasse escribió: > 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? > What are the exact pros and cons in terms of: > - font > - size > - memory consumption > > It seems that juan work is excellent for OS independence. > > Stef > > |
|
|
In reply to this post by Philippe Marschall
Hi Philippe,
Philippe Marschall escribió: > I don't see how the approach of Juan scales to: > - unicode I don't know if StrikeFonts are good for Unicode. If they are, I didn't break them. If they aren't, I didn't fix them. > - different fonts > - different font sizes Well,it does. Just build the bmp files and import them! > - different font styles (bold / italic / bold and italic) Automatically derived bold looks very nice (look at my page). Automatically derived italics works, but doesn't look great. But it is possible to build the bmps and import them. Cheers, Juan Vuletich > But maybe I just misunderstood something. > > Cheers > Philippe > > 2007/4/29, stephane ducasse <[hidden email]>: >> 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? >> What are the exact pros and cons in terms of: >> - font >> - size >> - memory consumption >> >> It seems that juan work is excellent for OS independence. >> >> Stef >> >> > > > |
Re: Font rendering strategy
|
|
2007/4/29, Juan Vuletich <[hidden email]>:
> Hi Philippe, > > Philippe Marschall escribió: > > I don't see how the approach of Juan scales to: > > - unicode > I don't know if StrikeFonts are good for Unicode. If they are, I didn't > break them. If they aren't, I didn't fix them. > > - different fonts > > - different font sizes > Well,it does. Just build the bmp files and import them! > > - different font styles (bold / italic / bold and italic) > Automatically derived bold looks very nice (look at my page). > Automatically derived italics works, but doesn't look great. But it is > possible to build the bmps and import them. > > Cheers, > Juan Vuletich > > But maybe I just misunderstood something. > > > > Cheers > > Philippe > > > > 2007/4/29, stephane ducasse <[hidden email]>: > >> 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? > >> What are the exact pros and cons in terms of: > >> - font > >> - size > >> - memory consumption > >> > >> It seems that juan work is excellent for OS independence. > >> > >> Stef > >> > >> > > > > > > > > > |
|
|
On 29/04/07, Philippe Marschall <[hidden email]> wrote:
> 2007/4/29, Juan Vuletich <[hidden email]>: > > Hi Philippe, > > > > Philippe Marschall escribió: > > > I don't see how the approach of Juan scales to: > > > - unicode > > I don't know if StrikeFonts are good for Unicode. If they are, I didn't > > break them. If they aren't, I didn't fix them. > > > - different fonts > > > - different font sizes > > Well,it does. Just build the bmp files and import them! > > For every possible font size?! > its not necessary to keep bitmaps for every point size. A good trick may be to use a largest possible font bitmap and for smaller sizes just scale it down using bilinear filter. |
|
|
In reply to this post by Philippe Marschall
Yes. Until you or somebody implements otherwise.
Cheers, Juan Vuletich Philippe Marschall escribió: > 2007/4/29, Juan Vuletich <[hidden email]>: >> Hi Philippe, >> >> Philippe Marschall escribió: >> > I don't see how the approach of Juan scales to: >> > - unicode >> I don't know if StrikeFonts are good for Unicode. If they are, I didn't >> break them. If they aren't, I didn't fix them. >> > - different fonts >> > - different font sizes >> Well,it does. Just build the bmp files and import them! > > For every possible font size?! > >> > - different font styles (bold / italic / bold and italic) >> Automatically derived bold looks very nice (look at my page). >> Automatically derived italics works, but doesn't look great. But it is >> possible to build the bmps and import them. >> >> Cheers, >> Juan Vuletich >> > But maybe I just misunderstood something. >> > >> > Cheers >> > Philippe >> > >> > 2007/4/29, stephane ducasse <[hidden email]>: >> >> 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? >> >> What are the exact pros and cons in terms of: >> >> - font >> >> - size >> >> - memory consumption >> >> >> >> It seems that juan work is excellent for OS independence. >> >> >> >> Stef >> >> >> >> >> > >> > >> > >> >> >> > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------ > > 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. > |
|
|
In reply to this post by stephane ducasse
Hi Stef,
----- Original Message ----- From: "stephane ducasse" <[hidden email]> To: "The general-purpose Squeak developers list" <[hidden email]> 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 |
|
|
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" <[hidden email]> > To: "The general-purpose Squeak developers list" > <[hidden email]> > 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 > > > |
|
|
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" <[hidden email]> >> To: "The general-purpose Squeak developers list" >> <[hidden email]> >> 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. > > |
|
|
In reply to this post by stephane ducasse
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'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: [hidden email] > Komu: [hidden email] > 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 > >[hidden email] 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. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |