Hi, here is a statistics I made about taking Squeak 3.10 and merging Cuis with it on the Morph hierarchy, just to have an idea on how much it could take...
Number of Classes removed in Cuis: 265 Number of Classes added on 3.10: 0 Number of Classes added on Cuis: 5 Number of Classes to merge: 59 Number of same methods: 930 Number of changed methods on Cuis: 117 Number of new methods on Cuis: 66 Number of conflicting methods: 44 (method on 3.7 is different that the one in 3.10 that in Cuis) Number of changed methods on current: 109 (from 3.7) Number of removed methods on Cuis: 796 Number of new methods in current: 2192
Hope it is useful!
On 4/17/09 5:47 PM, "Hernan Wilkinson" hernan.wilkinson@gmail.com wrote:
Hi, here is a statistics I made about taking Squeak 3.10 and merging Cuis with it on the Morph hierarchy, just to have an idea on how much it could take...
Number of Classes removed in Cuis: 265 Number of Classes added on 3.10: 0 Number of Classes added on Cuis: 5 Number of Classes to merge: 59 Number of same methods: 930 Number of changed methods on Cuis: 117 Number of new methods on Cuis: 66 Number of conflicting methods: 44 (method on 3.7 is different that the one in 3.10 that in Cuis) Number of changed methods on current: 109 (from 3.7) Number of removed methods on Cuis: 796 Number of new methods in current: 2192
Hope it is useful!
Hernan:
It¹s very useful. I know Juan put many hours on Cuis, too bad no time to learn of it and try to get all in my fork, which is 3.11 (as still NO 3.11 image , no matter one year of promises)
Edgar
Hernan: It’s very useful. I know Juan put many hours on Cuis, too bad no time to learn of it and try to get all in my fork, which is 3.11 (as still NO 3.11 image , no matter one year of promises) Edgar
One year of Edgar not reading or understanding. 3.11 effort is about process not an image. Similarly 4.0 is more about politics than an image.
Keith
"Keith" == Keith Hodges keith_hodges@yahoo.co.uk writes:
Keith> Similarly 4.0 is more about politics than an image.
I don't see that. The final result of 4.0 will be the 4.0 image, which will contain a tiny .changes file (almost nothing I hope) and a fully-OSI-licensed .sources file, from which we will be able to build the future.
I'd say that's quite a bit about the image.
Here are the same statistics but with Pharo dev 09.02.3, Squeak 3.7 and Cuis
Number of Classes removed in Cuis: 271 Number of Classes added on Pharo: 0 Number of new Classes in Cuis: 5 Number of Classes to merge: 59 Number of same methods: 858 Number of changed methods on Cuis: 91 Number of new methods on Cuis: 95 Number of conflicting methods: 66 (methods on 3.7 that different with the ones in Pharo and Cuis) Number of changed methods on Pharo: 162 (from 3.7) Number of removed methods on Cuis: 555 Number of new methods in Pharo: 2387
So, to merge Cuis Morph hierarchy with Pharo, 91+95 methods from Cuis have to be loaded in Pharo and 66 methods have to be integrated by a human. To merge Cuis Morph hierarchy with Squeak 3-10, 117+66 methods from Cuis have to be loaded in Squeak 3.10 and 44 methods have to be integrated by a human.
I ran the statistics only on the Morph hierarchy because what seems to be faster in Cuis is the UI. I'm assuming that the Cuis changes in the Morph hierarchy is what makes Cuis run faster, but I'm not sure of that... of course we can run the same process for other hierarchies, packages, all the classes, etc. And if somebody is interesting in knowing which classes, methods, etc. are involved (the real stuff, not only the numbers), just let me know.
Hernan.
On Fri, Apr 17, 2009 at 5:47 PM, Hernan Wilkinson < hernan.wilkinson@gmail.com> wrote:
Hi, here is a statistics I made about taking Squeak 3.10 and merging Cuis with it on the Morph hierarchy, just to have an idea on how much it could take...
Number of Classes removed in Cuis: 265 Number of Classes added on 3.10: 0 Number of Classes added on Cuis: 5 Number of Classes to merge: 59 Number of same methods: 930 Number of changed methods on Cuis: 117 Number of new methods on Cuis: 66 Number of conflicting methods: 44 (method on 3.7 is different that the one in 3.10 that in Cuis) Number of changed methods on current: 109 (from 3.7) Number of removed methods on Cuis: 796 Number of new methods in current: 2192
Hope it is useful!
On 4/17/09 9:58 PM, "Hernan Wilkinson" hernan.wilkinson@gmail.com wrote:
I ran the statistics only on the Morph hierarchy because what seems to be faster in Cuis is the UI. I'm assuming that the Cuis changes in the Morph hierarchy is what makes Cuis run faster, but I'm not sure of that... of course we can run the same process for other hierarchies, packages, all the classes, etc. And if somebody is interesting in knowing which classes, methods, etc. are involved (the real stuff, not only the numbers), just let me know.
Hernan.
I don¹t dig deeper in Cuis, but my bet is Cuis is faster as no TTF fonts. What people seems like , the Microsoft look, gives Vista perfomance :=)
Edgar
Hi!
At least on Linux I can't imagine why people would like the usual Squeak rendering, I may have a problem with Cuis as far as cut&paste is concerned, but it looks 1 million times better as far as fonts are concerned... Together with Opera and Chromium the usual Squeak way it's got the worst fonts rendering ever. Why?
I know nothing about char rendering in general, though. Maybe someone will take a second to explain me why certain things look so poor on *nix?
Berto
2009/4/18 Edgar J. De Cleene edgardec2001@yahoo.com.ar
I don’t dig deeper in Cuis, but my bet is Cuis is faster as no TTF fonts. What people seems like , the Microsoft look, gives Vista perfomance :=)
Edgar
On 20.04.2009, at 16:53, Bèrto ëd Sèra wrote:
Hi!
At least on Linux I can't imagine why people would like the usual Squeak rendering, I may have a problem with Cuis as far as cut&paste is concerned, but it looks 1 million times better as far as fonts are concerned... Together with Opera and Chromium the usual Squeak way it's got the worst fonts rendering ever. Why?
Linux and Windows users are accustomed to heavily hinted font rendering, looking overly "crisp" because lines are snapped to the screen pixel grid. The result has little resemblance to the true character shape as it would appear when printed on paper, but it's what they are used to. In contrast, Apple's and Adobe's font rendering is much more truthful to the paper appearance, but looks "blurry" to Windows and Linux users.
So it's much more a thing of taste than correctness for what people prefer. Here's a pretty nice discussion:
http://www.antigrain.com/research/font_rasterization/index.html
I know nothing about char rendering in general, though. Maybe someone will take a second to explain me why certain things look so poor on *nix?
Squeak's default truetype font rendering looks the same on all platforms, so it's not a *nix problem. It uses the Balloon2D engine, which renders vector fonts into bitmaps using 4x4 oversampling for anti-aliasing, without any hinting. The result looks more like the Apple rendering, which does not match the taste of many Linux/Windows users. And even Mac users usually have sub-pixel-rendering enabled which makes fonts look slightly crisper than what Balloon2D produces.
If you prefer the Linux font look, use the Freetype plugin. Well, or the Cuis fonts of course.
- Bert -
On Monday 20 April 2009 9:17:38 pm Bert Freudenberg wrote:
Linux and Windows users are accustomed to heavily hinted font rendering, looking overly "crisp" because lines are snapped to the screen pixel grid. The result has little resemblance to the true character shape as it would appear when printed on paper, but it's what they are used to. In contrast, Apple's and Adobe's font rendering is much more truthful to the paper appearance, but looks "blurry" to Windows and Linux users
Squeak's screen and its contents are meant to be consumed on bitmap monitors and rarely printed on paper, so why should the fonts be optimized for paper rendering and not display monitors?
Confused .. Subbu
On 24.04.2009, at 13:57, K. K. Subramaniam wrote:
On Monday 20 April 2009 9:17:38 pm Bert Freudenberg wrote:
Linux and Windows users are accustomed to heavily hinted font rendering, looking overly "crisp" because lines are snapped to the screen pixel grid. The result has little resemblance to the true character shape as it would appear when printed on paper, but it's what they are used to. In contrast, Apple's and Adobe's font rendering is much more truthful to the paper appearance, but looks "blurry" to Windows and Linux users
Squeak's screen and its contents are meant to be consumed on bitmap monitors and rarely printed on paper, so why should the fonts be optimized for paper rendering and not display monitors?
Confused .. Subbu
I tried not to argue too much one way or the other, just stating what the difference appears to be. As I wrote, it's mostly a matter of taste, and only secondly one of technology. It's still worth investigating why Balloon rendering looks so blurry, and if there can be done something about it.
- Bert -
On Fri, Apr 24, 2009 at 4:41 PM, Bert Freudenberg bert@freudenbergs.de wrote:
I tried not to argue too much one way or the other, just stating what the difference appears to be. As I wrote, it's mostly a matter of taste, and only secondly one of technology. It's still worth investigating why Balloon rendering looks so blurry, and if there can be done something about it.
Without having looked at the code, two problems that we encountered in Sophie: - multiple anti-aliasing (first the glyph, then when rendering the glyph image) - fractional position rendering (rendering an anti-aliased glyph onto a fractional pixel position)
Michael
On 25-Apr-09, at 2:02 AM, Michael Rueger wrote:
- fractional position rendering (rendering an anti-aliased glyph onto
a fractional pixel position)
Michael
Michael glosses over the fun details of do you round, or truncate, and as you accumulate float rounding errors what happens. So if you typed llllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll Er *maybe* somewhere the median visual density of one of those 'l' would be placed a pixel to the left or right of where it should have been.
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
On 25.04.2009, at 18:22, John M McIntosh wrote:
On 25-Apr-09, at 2:02 AM, Michael Rueger wrote:
- fractional position rendering (rendering an anti-aliased glyph onto
a fractional pixel position)
Michael
Michael glosses over the fun details of do you round, or truncate, and as you accumulate float rounding errors what happens. So if you typed llllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll Er *maybe* somewhere the median visual density of one of those 'l' would be placed a pixel to the left or right of where it should have been.
You both are seriously overestimating the sophistication of Squeak's standard text rendering ;)
It all derives from bitmap fonts, each glyph basically is a Form, and they are simply blitted one after the other onto the screen. No sub- pixel positioning, no kerning. The only thing that's different for TrueType fonts is how the forms are generated.
- Bert -
Is an external dependency like http://www.freetype.org/ completely out of the question?
On Sun, Apr 26, 2009 at 4:20 AM, Bert Freudenberg bert@freudenbergs.dewrote:
On 25.04.2009, at 18:22, John M McIntosh wrote:
On 25-Apr-09, at 2:02 AM, Michael Rueger wrote:
- fractional position rendering (rendering an anti-aliased glyph onto
a fractional pixel position)
You both are seriously overestimating the sophistication of Squeak's standard text rendering ;)
It all derives from bitmap fonts, each glyph basically is a Form, and they are simply blitted one after the other onto the screen. No sub-pixel positioning, no kerning. The only thing that's different for TrueType fonts is how the forms are generated.
On 26.04.2009, at 15:04, Steve Wart wrote:
Is an external dependency like http://www.freetype.org/ completely out of the question?
Not sure what you mean. There is a FreeType plugin already.
It does work for some applications. But besides huge plugins in general being not in the spirit of Smalltalk, one of the particular problems of using FreeType is that it depends on external fonts. But platform fonts vary largely between systems. That breaks one of the core promises of Squeak, platform independence.
Now I know the "re-inventing the wheel" argument. Which is why we made a Pango/FreeType rendering plugin for OLPC Etoys, where we need to support many more scripts than simple TrueType rendering could do. But it already starts to crumble. OLPC defined a platform, so we could rely on the fonts we used being installed. But now that Sugar became independent of OLPC, there is no control of the platform anymore really. Which means it's not guaranteed projects will look the same everywhere. We have not yet found a cheap solution to that problem.
- Bert -
On Sunday 26 April 2009 7:49:21 pm Bert Freudenberg wrote:
Not sure what you mean. There is a FreeType plugin already.
It does work for some applications. But besides huge plugins in general being not in the spirit of Smalltalk, one of the particular problems of using FreeType is that it depends on external fonts. But platform fonts vary largely between systems. That breaks one of the core promises of Squeak, platform independence.
There is another downside - the fonts design does not scale for many non-Roman languages. It divides glyphs on language and script basis instead of basic graphic shapes. Common sub-shapes are duplicated across fonts. Current rendering models support only rectangular bitblts which does not work very well for stroke-based compositions found in many Indian and Arabic scripts. Calligraphy is restricted to typeface designers.
An intriguing (and challenging) aspect of Squeak is the possibility of rendering texts in terms of graphical primitives and adding support for changing rendering algorithms on-the-fly. This would allow calligraphy and on-the-fly additions of new languages and scripts.
Those who fear the blue plane need not apply ;-).
Subbu
On Sun, Apr 26, 2009 at 7:19 AM, Bert Freudenberg bert@freudenbergs.dewrote:
On 26.04.2009, at 15:04, Steve Wart wrote:
Is an external dependency like http://www.freetype.org/ completely out of the question?
Not sure what you mean. There is a FreeType plugin already.
Funny. I had installed it only 2 months ago and spent several hours trying to get it to work/work well in Cobalt before deciding that Accuny looked better than any of the several dozen fonts I scoured through. Don't know why I didn't think about that before I posted.
I mentioned because I had been coincidentally looking at GLTT (for another project) to render some TT fonts in OpenGL and probably read too much into the coincidence.
It does work for some applications. But besides huge plugins in general
being not in the spirit of Smalltalk, one of the particular problems of using FreeType is that it depends on external fonts. But platform fonts vary largely between systems. That breaks one of the core promises of Squeak, platform independence.
I think this is a problem for a lot of projects and maybe FreeType isn't the answer. But it would be nice to have an alternative to the bitmap fonts and the TrueType model is very rich (I don't know if it's rich enough for all human languages but if there is another model that can live up to that standard I'd be interested to find out more). Many decent free fonts are available so I don't think external dependencies need to be an issue (they're just data), but I don't understand why fonts tend to be a platform problem. How is font rendering/lookup dependent on the underlying OS? Can that dependency be broken?
Now I know the "re-inventing the wheel" argument. Which is why we made a Pango/FreeType rendering plugin for OLPC Etoys, where we need to support many more scripts than simple TrueType rendering could do. But it already starts to crumble. OLPC defined a platform, so we could rely on the fonts we used being installed. But now that Sugar became independent of OLPC, there is no control of the platform anymore really. Which means it's not guaranteed projects will look the same everywhere. We have not yet found a cheap solution to that problem.
It does make sense in some contexts to do everything in Smalltalk. Clearly changing the font model is a huge amount of work and there is a long legacy of development that depends on fonts working the way they do now. But Squeak has for years shipped with its own fonts installed, why do we need to depend on the platform for that?
Steve
On 27.04.2009, at 17:30, Steve Wart wrote:
On Sun, Apr 26, 2009 at 7:19 AM, Bert Freudenberg <bert@freudenbergs.de
wrote:
On 26.04.2009, at 15:04, Steve Wart wrote:
Is an external dependency like http://www.freetype.org/ completely out of the question?
Not sure what you mean. There is a FreeType plugin already.
Funny. I had installed it only 2 months ago and spent several hours trying to get it to work/work well in Cobalt before deciding that Accuny looked better than any of the several dozen fonts I scoured through. Don't know why I didn't think about that before I posted.
I mentioned because I had been coincidentally looking at GLTT (for another project) to render some TT fonts in OpenGL and probably read too much into the coincidence.
It does work for some applications. But besides huge plugins in general being not in the spirit of Smalltalk, one of the particular problems of using FreeType is that it depends on external fonts. But platform fonts vary largely between systems. That breaks one of the core promises of Squeak, platform independence.
I think this is a problem for a lot of projects and maybe FreeType isn't the answer. But it would be nice to have an alternative to the bitmap fonts and the TrueType model is very rich (I don't know if it's rich enough for all human languages but if there is another model that can live up to that standard I'd be interested to find out more). Many decent free fonts are available so I don't think external dependencies need to be an issue (they're just data), but I don't understand why fonts tend to be a platform problem. How is font rendering/lookup dependent on the underlying OS? Can that dependency be broken?
By bundling fonts, sure. But trying to convince Linux package maintainers that this is a necessity ... that's going to be hard.
Now I know the "re-inventing the wheel" argument. Which is why we made a Pango/FreeType rendering plugin for OLPC Etoys, where we need to support many more scripts than simple TrueType rendering could do. But it already starts to crumble. OLPC defined a platform, so we could rely on the fonts we used being installed. But now that Sugar became independent of OLPC, there is no control of the platform anymore really. Which means it's not guaranteed projects will look the same everywhere. We have not yet found a cheap solution to that problem.
It does make sense in some contexts to do everything in Smalltalk. Clearly changing the font model is a huge amount of work and there is a long legacy of development that depends on fonts working the way they do now. But Squeak has for years shipped with its own fonts installed, why do we need to depend on the platform for that?
We don't need to, true, but in their current form the plugins cannot render fonts embedded in the image.
- Bert -
I wonder, why we should care bundling TT fonts with squeak?
As well as why we should sacrifice the quality to the abstract 'be identical on all platforms' idea?
For me, it is strange to even see a phrases like 'be bit identical everywhere'. Is this the most important thing we should care about when dealing with font rendering??? Let turn our face to the end users: for font rendering a most important aspect is quality. And from user's perspective an overall quality is a balance between two categories: - do things fast (so UI is fast & responsive) - render glyphs with a good quality so users can read text on display without hurting their eyes.
2009/4/27 Bert Freudenberg bert@freudenbergs.de:
On 27.04.2009, at 17:30, Steve Wart wrote:
On Sun, Apr 26, 2009 at 7:19 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 26.04.2009, at 15:04, Steve Wart wrote:
Is an external dependency like http://www.freetype.org/ completely out of the question?
Not sure what you mean. There is a FreeType plugin already.
Funny. I had installed it only 2 months ago and spent several hours trying to get it to work/work well in Cobalt before deciding that Accuny looked better than any of the several dozen fonts I scoured through. Don't know why I didn't think about that before I posted.
I mentioned because I had been coincidentally looking at GLTT (for another project) to render some TT fonts in OpenGL and probably read too much into the coincidence.
It does work for some applications. But besides huge plugins in general being not in the spirit of Smalltalk, one of the particular problems of using FreeType is that it depends on external fonts. But platform fonts vary largely between systems. That breaks one of the core promises of Squeak, platform independence.
I think this is a problem for a lot of projects and maybe FreeType isn't the answer. But it would be nice to have an alternative to the bitmap fonts and the TrueType model is very rich (I don't know if it's rich enough for all human languages but if there is another model that can live up to that standard I'd be interested to find out more). Many decent free fonts are available so I don't think external dependencies need to be an issue (they're just data), but I don't understand why fonts tend to be a platform problem. How is font rendering/lookup dependent on the underlying OS? Can that dependency be broken?
By bundling fonts, sure. But trying to convince Linux package maintainers that this is a necessity ... that's going to be hard.
Now I know the "re-inventing the wheel" argument. Which is why we made a Pango/FreeType rendering plugin for OLPC Etoys, where we need to support many more scripts than simple TrueType rendering could do. But it already starts to crumble. OLPC defined a platform, so we could rely on the fonts we used being installed. But now that Sugar became independent of OLPC, there is no control of the platform anymore really. Which means it's not guaranteed projects will look the same everywhere. We have not yet found a cheap solution to that problem.
It does make sense in some contexts to do everything in Smalltalk. Clearly changing the font model is a huge amount of work and there is a long legacy of development that depends on fonts working the way they do now. But Squeak has for years shipped with its own fonts installed, why do we need to depend on the platform for that?
We don't need to, true, but in their current form the plugins cannot render fonts embedded in the image.
- Bert -
Bert wrote
By bundling fonts, sure. But trying to convince Linux package maintainers that this is a necessity ... that's going to be hard.
[..snip...]
We don't need to, true, but in their current form the plugins cannot
render
fonts embedded in the image.
On Mon, Apr 27, 2009 at 8:46 PM, Igor Stasenko siguctua@gmail.com wrote:
I wonder, why we should care bundling TT fonts with squeak?
It seems that it should be possible to separate identification and loading of fonts (could be platform-dependent) from the rendering of fonts (ideally not platform-dependent).
It would be nice instead of worrying about how Microsoft does it or Apple does it to instead use a platform-independent hardware abstraction like OpenGL. I know this won't work on some platforms but it will work on most, and GLES is looking to be well-supported on future low-power devices. This might also be an elegant way to improve the somewhat uncomfortable relationship between OpenGL worlds and the rest of the Squeak environment.
On 2009-04-25 11:02, Michael Rueger wrote:
On Fri, Apr 24, 2009 at 4:41 PM, Bert Freudenbergbert@freudenbergs.de wrote:
I tried not to argue too much one way or the other, just stating what the difference appears to be. As I wrote, it's mostly a matter of taste, and only secondly one of technology. It's still worth investigating why Balloon rendering looks so blurry, and if there can be done something about it.
Without having looked at the code, two problems that we encountered in Sophie:
- multiple anti-aliasing (first the glyph, then when rendering the glyph image)
This sounds time consuming. Did you guys fix this ?
Karl
- fractional position rendering (rendering an anti-aliased glyph onto
a fractional pixel position)
Michael
Karl Ramberg wrote:
- multiple anti-aliasing (first the glyph, then when
rendering the glyph image)
This sounds time consuming. Did you guys fix this ?
Yes, you have to make sure you only blit glyphs (not image render them in Cairo) and only to integer pixel coordinates.
Michael
K. K. Subramaniam wrote:
On Monday 20 April 2009 9:17:38 pm Bert Freudenberg wrote:
Linux and Windows users are accustomed to heavily hinted font rendering, looking overly "crisp" because lines are snapped to the screen pixel grid. The result has little resemblance to the true character shape as it would appear when printed on paper, but it's what they are used to. In contrast, Apple's and Adobe's font rendering is much more truthful to the paper appearance, but looks "blurry" to Windows and Linux users
Squeak's screen and its contents are meant to be consumed on bitmap monitors and rarely printed on paper, so why should the fonts be optimized for paper rendering and not display monitors?
Confused .. Subbu
Hi Subbu,
It isn't a question of optimization for a particular medium. Printers can render fonts at high resolution, so the quality of the rendering is quite good: crisp edges, smooth curves and high fidelity to the letter shapes defined by the font. Screens are much lower resolution, and especially at smaller point sizes, it's impossible to match the rendering quality of a printer.
So how do we get a good image at low resolution? Apple's strategy is to alter the *intensity* of certain pixels in the rendered image to preserve fidelity to the letter shapes and provide the illusion of smooth curves. Microsoft's strategy is to alter the *position* of certain pixels in the rendered image to preserve the crisp edges that one finds in printed text.
Apple emphasizes fidelity to the font's character shapes, resulting in bluriness, while Microsoft emphasizes clarity, resulting in distortion. Either is a reasonable choice.
Colin
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Bèrto ëd Sèra -
Colin Putney -
Edgar J. De Cleene -
Hernan Wilkinson -
Igor Stasenko -
John M McIntosh -
K. K. Subramaniam -
Karl Ramberg -
Keith Hodges -
merlyn＠stonehenge.com -
Michael Rueger -
Steve Wart