Hi Folks,
If you update to the latest trunk, you'll load Graphics-jmv.53, Morphic-jmv.138 and System-jmv.118. This is the support for anti aliased StrikeFonts from Cuis. The new 'BitmapDejaVu' font of point size 9 is set as default. I only included size 9 (reg, italic, bold, bold italic) to avoid using too much space in the image. If people want, more sizes can be added.
To do proper antialiasing / subpixel AA _without_ requiring new BitBlt modes, I use RGBMul BitBlt rule, and a second pass with RGBAdd rule. Text looks very good, in any combination of font and background colors, even at lower Display depths and / or glyphs depths.
By default underscore and caret are shown as in standard ASCII. If you prefer the classic ST-80 left and up arrow, evaluate 'StrikeFont useLeftArrow'. To go back to the default, evaluate 'StrikeFont useUnderscore'. I also added 2 preferences #subPixelRenderFonts and #subPixelRenderColorFonts (both default to true).
Andreas, thanks for all your help!
Comments are welcome.
Cheers, Juan Vuletich
On Mon, Aug 03, 2009 at 06:52:47PM -0300, Juan Vuletich wrote:
Hi Folks,
If you update to the latest trunk, you'll load Graphics-jmv.53, Morphic-jmv.138 and System-jmv.118. This is the support for anti aliased StrikeFonts from Cuis. The new 'BitmapDejaVu' font of point size 9 is set as default. I only included size 9 (reg, italic, bold, bold italic) to avoid using too much space in the image. If people want, more sizes can be added.
To do proper antialiasing / subpixel AA _without_ requiring new BitBlt modes, I use RGBMul BitBlt rule, and a second pass with RGBAdd rule. Text looks very good, in any combination of font and background colors, even at lower Display depths and / or glyphs depths.
By default underscore and caret are shown as in standard ASCII. If you prefer the classic ST-80 left and up arrow, evaluate 'StrikeFont useLeftArrow'. To go back to the default, evaluate 'StrikeFont useUnderscore'. I also added 2 preferences #subPixelRenderFonts and #subPixelRenderColorFonts (both default to true).
Andreas, thanks for all your help!
Comments are welcome.
Nicely done, thanks for this!
FYI, I did encounter a couple of glitches in doing the update. First, I got a dialog saying "the map is more than 10 days old" (or something like that), which I think may come from SqueakMap. After redoing the update, all was well.
I then tried the update again (starting with my original image), and did not get the "more than 10 days old" dialog (presumably because I had updated the map), but then I did get an error while loading System-jmv.118, see attached png.
In both cases, re-doing the update makes everything work, and I have the new Cuis StrikeFonts loaded now.
Thanks!
Dave
David T. Lewis wrote:
FYI, I did encounter a couple of glitches in doing the update. First, I got a dialog saying "the map is more than 10 days old" (or something like that), which I think may come from SqueakMap. After redoing the update, all was well.
This appears to be happening when the flaps get recreated. I found that the best thing to do is to say "No" and continue updating (I had no problems afterwards).
Cheers, - Andreas
Juan Vuletich wrote:
If you update to the latest trunk, you'll load Graphics-jmv.53, Morphic-jmv.138 and System-jmv.118. This is the support for anti aliased StrikeFonts from Cuis. The new 'BitmapDejaVu' font of point size 9 is set as default. I only included size 9 (reg, italic, bold, bold italic) to avoid using too much space in the image. If people want, more sizes can be added.
Thanks Juan, this is really great. If folks haven't tried it yet you should - it does really make a difference (and I'll update a trunk image soon so that you get the nicer fonts out of the box). About more sizes - I think the one additional thing I'd wish is a size suitable for Window titles. It looks odd to have nice fonts in texts and lists (and the chosen font is great for that) and then not-so-nice fonts for the Window titles. I tried using the 9pt font for titles but it's just a wee bit too small.
Other than that: Way to go!
Cheers, - Andreas
To do proper antialiasing / subpixel AA _without_ requiring new BitBlt modes, I use RGBMul BitBlt rule, and a second pass with RGBAdd rule. Text looks very good, in any combination of font and background colors, even at lower Display depths and / or glyphs depths.
By default underscore and caret are shown as in standard ASCII. If you prefer the classic ST-80 left and up arrow, evaluate 'StrikeFont useLeftArrow'. To go back to the default, evaluate 'StrikeFont useUnderscore'. I also added 2 preferences #subPixelRenderFonts and #subPixelRenderColorFonts (both default to true).
Andreas, thanks for all your help!
Comments are welcome.
Cheers, Juan Vuletich
Hi!
Andreas Raab wrote:
Other than that: Way to go!
First of all - superb work! And really nice to see how work from Cuis enter squeak.org.
Just one silly question:
To do proper antialiasing / subpixel AA _without_ requiring new BitBlt modes, I use RGBMul BitBlt rule, and a second pass with RGBAdd rule.
So... is this a better approach than adding new bitblt modes or is it just equally fine? Just wondering, I have no knowledge in this area.
regards, Göran
Hi Goran,
Göran Krampe wrote:
Hi!
Andreas Raab wrote:
Other than that: Way to go!
First of all - superb work! And really nice to see how work from Cuis enter squeak.org.
Just one silly question:
To do proper antialiasing / subpixel AA _without_ requiring new BitBlt modes, I use RGBMul BitBlt rule, and a second pass with RGBAdd rule.
So... is this a better approach than adding new bitblt modes or is it just equally fine? Just wondering, I have no knowledge in this area.
It is not a silly question at all!
I've been playing with the idea of arbitrary depth StrikeFonts for about 2 years now. Until recently, my objective was to do the best that could be done without requiring new plugins, even if far from perfect. Then, in May, Andy Tween (the author of the new BitBlt rule) said in VM-dev: "I believe that the existing bitBlt rules are insufficient to cover all these circumstances, but I am happy to be proved wrong :)". So I started thinking about it, and I realized they are indeed enough, and came out with this two pass idea. BTW, black text only needs the first pass. So, it is even faster than the new mode for black text.
So far, they give exactly the same result. The differences might appear for Display depths of 8 bits and less (RGBMul / RGBAdd don't work there, and I guess Rule 41 won't work either). Something I like of my approach is how well it works even with 4bpp glyps (to save space), and the fact it never uses extra glyph caches. It does all it magic with just one glyph definition for each font/character, just like older StrikeFonts. So memory consumptions is predictable, once the font is created, no more objects are created. And there is no Weak / GC stress at all. On the other hand, Rule 41 supports gamma correction. I really don't know how important this might be for text.
BTW, this 2-pass idea could be used to render any kind of font (or any kind of bitmap object). It could be useful for rendering TTCFonts and FT2Fonts too, avoiding the need to create colored glyphs cache.
Cheers, Juan Vuletich
regards, Göran
Andreas Raab wrote:
Juan Vuletich wrote:
If you update to the latest trunk, you'll load Graphics-jmv.53, Morphic-jmv.138 and System-jmv.118. This is the support for anti aliased StrikeFonts from Cuis. The new 'BitmapDejaVu' font of point size 9 is set as default. I only included size 9 (reg, italic, bold, bold italic) to avoid using too much space in the image. If people want, more sizes can be added.
Thanks Juan, this is really great. If folks haven't tried it yet you should - it does really make a difference (and I'll update a trunk image soon so that you get the nicer fonts out of the box). About more sizes - I think the one additional thing I'd wish is a size suitable for Window titles. It looks odd to have nice fonts in texts and lists (and the chosen font is great for that) and then not-so-nice fonts for the Window titles. I tried using the 9pt font for titles but it's just a wee bit too small.
Other than that: Way to go!
Cheers,
- Andreas
:)
I have just updated the trunk again. I added 12pt and set it as default for window titles (in bold). I also added 7pt. It takes little space and it is great for pdas or if you have sharp eyes.
Cheers, Juan Vuletich
Juan Vuletich wrote:
I have just updated the trunk again. I added 12pt and set it as default for window titles (in bold). I also added 7pt. It takes little space and it is great for pdas or if you have sharp eyes.
Very cool. I noticed one small issue when I was trying to make screen shots with the fonts: For black text, the resulting output doesn't seem have the alpha channel set which leads to some odd effects like in the attached image (notice however that the white-on-blue text looks fine). You can kinda guess what it's supposed to look like when you load it into Squeak and do a #fixAlpha on it but it would be good if we could generate a "proper" alpha channel. Any ideas what might be causing this?
Cheers, - Andreas
Andreas Raab wrote:
Juan Vuletich wrote:
I have just updated the trunk again. I added 12pt and set it as default for window titles (in bold). I also added 7pt. It takes little space and it is great for pdas or if you have sharp eyes.
Very cool. I noticed one small issue when I was trying to make screen shots with the fonts: For black text, the resulting output doesn't seem have the alpha channel set which leads to some odd effects like in the attached image (notice however that the white-on-blue text looks fine). You can kinda guess what it's supposed to look like when you load it into Squeak and do a #fixAlpha on it but it would be good if we could generate a "proper" alpha channel. Any ideas what might be causing this?
Cheers,
- Andreas
You're right. It seems we need the second BitBlt pass even for black text. Just added that to the trunk. I also added a preference, #properAlphaForBlackText that defaults to true, but can be set to false if performance is more important that correctness.
Note #1. This needs a rather recent VM, that includes my fixes to BitBlt done in April. Your latest Windows VM is ok.
Note #2. If the trend is to fix the handling of alpha channel in the image, at some point the fix to ignore Display alpha must be removed from the Linux VM, to play well with composing window managers.
Note #3. The second pass stuff is done in GrafPort, but not in BitBlt. Do you think it is better to move it up to BitBlt?
Cheers, Juan Vuletich
Juan Vuletich wrote:
Andreas Raab wrote:
Juan Vuletich wrote:
I have just updated the trunk again. I added 12pt and set it as default for window titles (in bold). I also added 7pt. It takes little space and it is great for pdas or if you have sharp eyes.
Very cool. I noticed one small issue when I was trying to make screen shots with the fonts: For black text, the resulting output doesn't seem have the alpha channel set which leads to some odd effects like in the attached image (notice however that the white-on-blue text looks fine). You can kinda guess what it's supposed to look like when you load it into Squeak and do a #fixAlpha on it but it would be good if we could generate a "proper" alpha channel. Any ideas what might be causing this?
Cheers,
- Andreas
You're right. It seems we need the second BitBlt pass even for black text. Just added that to the trunk. I also added a preference, #properAlphaForBlackText that defaults to true, but can be set to false if performance is more important that correctness.
Note #1. This needs a rather recent VM, that includes my fixes to BitBlt done in April. Your latest Windows VM is ok.
Note #2. If the trend is to fix the handling of alpha channel in the image, at some point the fix to ignore Display alpha must be removed from the Linux VM, to play well with composing window managers.
Note #3. The second pass stuff is done in GrafPort, but not in BitBlt. Do you think it is better to move it up to BitBlt?
Ok. I moved the double pass up to BitBlt, to avoid loss of quality if rendering without a GrafPort. I don't know if that is ever done, but this way it is more consistent.
Cheers, Juan Vuletich
Juan,
the new StrikeFonts look nicely crisp, but the letter spacing seems to be off. Compare this new to old rendering:
Can this be made more homogenous? The space after the "r" seems to be too large, and the sequence "lit" looks very uneven compared to the right, older shot.
Secondly, can the sub-pixel AA be disabled on the fly? It leads to visible color fringes when the subpixel layout does not match your AA.
- Bert -
Bert Freudenberg wrote:
Juan,
the new StrikeFonts look nicely crisp, but the letter spacing seems to be off. Compare this new to old rendering:
(image snipped)
Can this be made more homogenous? The space after the "r" seems to be too large, and the sequence "lit" looks very uneven compared to the right, older shot.
I created the fonts automatically, from a sample rendered with FreeType, using area each glyph uses. In this case, the $r has a very light blue pixel at the topRight. I can modify the script to ignore pixels that are too light when setting the bounds for the glyph, but I can not guarantee perfect results unless glyphs are tweaked by hand.
Secondly, can the sub-pixel AA be disabled on the fly? It leads to visible color fringes when the subpixel layout does not match your AA.
Sure. See Preference #subPixelRenderFonts.
Cheers, Juan Vuletich
- Bert -
On 05.08.2009, at 18:17, Juan Vuletich wrote:
Bert Freudenberg wrote:
Juan,
the new StrikeFonts look nicely crisp, but the letter spacing seems to be off. Compare this new to old rendering:
(image snipped)
Can this be made more homogenous? The space after the "r" seems to be too large, and the sequence "lit" looks very uneven compared to the right, older shot.
I created the fonts automatically, from a sample rendered with FreeType, using area each glyph uses. In this case, the $r has a very light blue pixel at the topRight. I can modify the script to ignore pixels that are too light when setting the bounds for the glyph, but I can not guarantee perfect results unless glyphs are tweaked by hand.
Yes, under magnification I see thew problem ... oh well :)
Secondly, can the sub-pixel AA be disabled on the fly? It leads to visible color fringes when the subpixel layout does not match your AA.
Sure. See Preference #subPixelRenderFonts.
Hmm, this does not show up in the Preferences panel ... also, when I disable that, all pixels become full black, so this is unusable.
- Bert -
Bert Freudenberg wrote:
On 05.08.2009, at 18:17, Juan Vuletich wrote:
Bert Freudenberg wrote:
Juan,
the new StrikeFonts look nicely crisp, but the letter spacing seems to be off. Compare this new to old rendering:
(image snipped)
Can this be made more homogenous? The space after the "r" seems to be too large, and the sequence "lit" looks very uneven compared to the right, older shot.
I created the fonts automatically, from a sample rendered with FreeType, using area each glyph uses. In this case, the $r has a very light blue pixel at the topRight. I can modify the script to ignore pixels that are too light when setting the bounds for the glyph, but I can not guarantee perfect results unless glyphs are tweaked by hand.
Yes, under magnification I see thew problem ... oh well :)
I'll play a bit with this for the next trunk update I do.
Secondly, can the sub-pixel AA be disabled on the fly? It leads to visible color fringes when the subpixel layout does not match your AA.
Sure. See Preference #subPixelRenderFonts.
Hmm, this does not show up in the Preferences panel ... also, when I disable that, all pixels become full black, so this is unusable.
- Bert -
It should work ok, doing gray AA. It must be some problem we introduced in one of the very last trunk updates. Will fix it. Expect a new version in the trunk tonight.
Cheers, Juan Vuletich
Hi Folks,
A new version of the new StrikeFonts is in the trunk.
Bert Freudenberg wrote:
On 05.08.2009, at 18:17, Juan Vuletich wrote:
Bert Freudenberg wrote:
Juan,
the new StrikeFonts look nicely crisp, but the letter spacing seems to be off. Compare this new to old rendering:
(image snipped)
Can this be made more homogenous? The space after the "r" seems to be too large, and the sequence "lit" looks very uneven compared to the right, older shot.
I created the fonts automatically, from a sample rendered with FreeType, using area each glyph uses. In this case, the $r has a very light blue pixel at the topRight. I can modify the script to ignore pixels that are too light when setting the bounds for the glyph, but I can not guarantee perfect results unless glyphs are tweaked by hand.
Yes, under magnification I see thew problem ... oh well :)
I fixed it. I added an heuristic to the font build script, to discard some very light pixels. It looks quite nicer! It will never be as precise as a real TrueType renderer, as StrikeFont can't adjust kerning based on the shape of glyphs. But it is better than before.
If you see some glyph that could use further tweaking, please tell.
I also made digits from $0 to $9 to be monospaced. This is nice when looking at columns of numbers.
Secondly, can the sub-pixel AA be disabled on the fly? It leads to visible color fringes when the subpixel layout does not match your AA.
Sure. See Preference #subPixelRenderFonts.
Hmm, this does not show up in the Preferences panel ... also, when I disable that, all pixels become full black, so this is unusable.
This is fixed too. BTW, if you're using gray AA and don't care about getting subpixelAA anymore, you can do StrikeFont allInstances do: [ :f | f setGlyphsDepthAtMost: 4]. This will make the fonts use 4 bpp, i.e. 8 gray levels. (In Squeak, Forms of 4bpp have 8 gray levels and 8 saturated colors). This is quite enough for gray AA. And it will save a lot of space.
I also fixed the other issues pending. The dual pass is done at BitBlt and not only GrafPort, and as no new ivars are added, WarpBlt works ok too.
Finally, the second BitBlt pass should not be needed for black text, but it is needed right now due to a bug in BitBlt. I expect the VMs to be fixed in a couple of months. Then, I can adjust the image code to avoid the second pass if possible.
Cheers, Juan Vuletich
On 06.08.2009, at 04:34, Juan Vuletich wrote:
I fixed it. I added an heuristic to the font build script, to discard some very light pixels. It looks quite nicer!
Indeed :)
Sure. See Preference #subPixelRenderFonts.
Hmm, this does not show up in the Preferences panel ... also, when I disable that, all pixels become full black, so this is unusable.
This is fixed too. BTW, if you're using gray AA and don't care about getting subpixelAA anymore, you can do StrikeFont allInstances do: [ :f | f setGlyphsDepthAtMost: 4]. This will make the fonts use 4 bpp, i.e. 8 gray levels. (In Squeak, Forms of 4bpp have 8 gray levels and 8 saturated colors). This is quite enough for gray AA. And it will save a lot of space.
Yes works fine now.
One issue I see is when you open appearance - system fonts then in my image the "window-title font" displays incorrectly. Strangely, I chose the same font (BitmapDejaVu-12-Bold) as "Etoys title font" and that shows up fine.
Another issue in that menu is that the currently selected font used to be highlighted in blue. For the new bitmap fonts this does not happen.
- Bert -
Hi Bert,
Bert Freudenberg wrote:
...
One issue I see is when you open appearance - system fonts then in my image the "window-title font" displays incorrectly. Strangely, I chose the same font (BitmapDejaVu-12-Bold) as "Etoys title font" and that shows up fine.
Another issue in that menu is that the currently selected font used to be highlighted in blue. For the new bitmap fonts this does not happen.
- Bert -
Both fixed in the trunk now. Thanks for the feedback!
Cheers, Juan Vuletich
On 06.08.2009, at 15:20, Juan Vuletich wrote:
Hi Bert,
Bert Freudenberg wrote:
...
One issue I see is when you open appearance - system fonts then in my image the "window-title font" displays incorrectly. Strangely, I chose the same font (BitmapDejaVu-12-Bold) as "Etoys title font" and that shows up fine.
Another issue in that menu is that the currently selected font used to be highlighted in blue. For the new bitmap fonts this does not happen.
- Bert -
Both fixed in the trunk now. Thanks for the feedback!
Thanks for fixing :) Somehow Squeak feels "alive" again ...
- Bert -
Juan Vuletich wrote:
You're right. It seems we need the second BitBlt pass even for black text. Just added that to the trunk. I also added a preference, #properAlphaForBlackText that defaults to true, but can be set to false if performance is more important that correctness.
Yeah, good choice. It turns out that there is a measurable performance difference between single-pass and two-pass rendering (for example in the browser benchmark). Is it possible to merge these specific two rules into a single-pass rendering to retain the original single-pass performance?
Note #1. This needs a rather recent VM, that includes my fixes to BitBlt done in April. Your latest Windows VM is ok.
Note #2. If the trend is to fix the handling of alpha channel in the image, at some point the fix to ignore Display alpha must be removed from the Linux VM, to play well with composing window managers.
Yes, we should. It would be nice if we could actually control the alpha correctly.
Note #3. The second pass stuff is done in GrafPort, but not in BitBlt. Do you think it is better to move it up to BitBlt?
BitBlt, since it's used directly from StrikeFont and not via Canvas.
Cheers, - Andreas
Andreas Raab wrote:
Note #3. The second pass stuff is done in GrafPort, but not in BitBlt. Do you think it is better to move it up to BitBlt?
BitBlt, since it's used directly from StrikeFont and not via Canvas.
Or that's what he thought. It turns out this doesn't work since it breaks WarpBlt (which relies on the exact layout of BitBlt). I suppose *that* is the reason why GrafPort got invented to begin with (it always felt strange to me since Morphic had both Canvas and BitBlt and should be happy inbetween the two - but if adding state to BB isn't an option, that would explain GrafPort).
In any case, I pushed the state vars back down to GrafPort (renaming them in the process to avoid Monticello madness) and hopefully everything is fine now. You'll have to use GrafPort to get two-pass rendering but it won't break if you use BitBlt.
Cheers, - Andreas
Andreas Raab wrote:
Andreas Raab wrote:
Note #3. The second pass stuff is done in GrafPort, but not in BitBlt. Do you think it is better to move it up to BitBlt?
BitBlt, since it's used directly from StrikeFont and not via Canvas.
Or that's what he thought. It turns out this doesn't work since it breaks WarpBlt (which relies on the exact layout of BitBlt). I suppose *that* is the reason why GrafPort got invented to begin with (it always felt strange to me since Morphic had both Canvas and BitBlt and should be happy inbetween the two - but if adding state to BB isn't an option, that would explain GrafPort).
In any case, I pushed the state vars back down to GrafPort (renaming them in the process to avoid Monticello madness) and hopefully everything is fine now. You'll have to use GrafPort to get two-pass rendering but it won't break if you use BitBlt.
I managed to add the behavior back to BitBlt without adding any instance variables. It is a bit hacky, as #displayString:from:to:at:strikeFont:kern: needs to assume that if rule is rgbMul, a second pass is in order. I prefer this, as it would give proper rendering when not using a GrafPort / MorphicCanvas.
If you don't object, I'll upload this to the trunk later today.
BTW, as I said in another message, once we fix rgbMul in BitBlt, the second pass will only be needed for colored text.
Cheers, Juan Vuletich
Cheers,
- Andreas
Juan Vuletich wrote:
I managed to add the behavior back to BitBlt without adding any instance variables. It is a bit hacky, as #displayString:from:to:at:strikeFont:kern: needs to assume that if rule is rgbMul, a second pass is in order. I prefer this, as it would give proper rendering when not using a GrafPort / MorphicCanvas.
Ah, very clever ;-)
If you don't object, I'll upload this to the trunk later today.
Sounds good, just make sure you add a comment or else some people will be horribly confused about what this is all about two years down the road ;-)
BTW, as I said in another message, once we fix rgbMul in BitBlt, the second pass will only be needed for colored text.
Yup, I also saw your message on vm-dev.
Cheers, - Andreas
Andreas Raab wrote:
Juan Vuletich wrote:
You're right. It seems we need the second BitBlt pass even for black text. Just added that to the trunk. I also added a preference, #properAlphaForBlackText that defaults to true, but can be set to false if performance is more important that correctness.
Yeah, good choice. It turns out that there is a measurable performance difference between single-pass and two-pass rendering (for example in the browser benchmark). Is it possible to merge these specific two rules into a single-pass rendering to retain the original single-pass performance?
Well, each uses a different colorMap, so it is a bit tricky. On the other hand, for black text, the second pass really should not be necessary. When we get this right (more below), then the price for the second pass is only paid for colored text.
The second pass is currently needed because of a bug in BitBlt. The following code f1 := Form extent: 8@8 depth: 32. f1 fillColor: (Color r: 1.0 g: 1.0 b: 0.7 alpha: 0.7). f2 := Form extent: 8@8 depth: 32. f2 fillColor: (Color r: 0.5 g: 1.0 b: 0.7 alpha: 0.9). bb :=(BitBlt toForm: f1) sourceForm: f2; combinationRule: 37; copyBits. (f1 colorAt: 2@2) should evaluate to (TranslucentColor r: 0.501 g: 1.0 b: 0.494 alpha: 0.627), but answers Color transparent. The problem is in #partitionedMul:with:nBits:nPartitions: as it ignores the last argument. Will send a mail to VM-dev about this.
Cheers, Juan Vuletich
Note #1. This needs a rather recent VM, that includes my fixes to BitBlt done in April. Your latest Windows VM is ok.
Note #2. If the trend is to fix the handling of alpha channel in the image, at some point the fix to ignore Display alpha must be removed from the Linux VM, to play well with composing window managers.
Yes, we should. It would be nice if we could actually control the alpha correctly.
Note #3. The second pass stuff is done in GrafPort, but not in BitBlt. Do you think it is better to move it up to BitBlt?
BitBlt, since it's used directly from StrikeFont and not via Canvas.
Cheers,
- Andreas
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.44/2282 - Release Date: 08/04/09 18:01:00
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
David T. Lewis -
Göran Krampe -
Juan Vuletich