- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Error when 'Loading 11313-Pha-CleaningCompilerTests...'

by Sean P. DeNigris

> Hi, I think this is a common error caused by corrupt mcz files. Can > you clear your cache and try again? Sure, how do I clear the cache? Also, it was a totally fresh image downloaded from the site. Sean DeNigris -- View this message in context: http://n4.nabble.com/Error-when-Loading-11313-Pha-CleaningCompilerTests-tp2… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 19, 2010

Re: [Pharo-project] Error when 'Loading 11313-Pha-CleaningCompilerTests...'

by Michael Roberts

Hi, I think this is a common error caused by corrupt mcz files. Can you clear your cache and try again? thanks, Mike On Mon, Apr 19, 2010 at 6:47 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > http://code.google.com/p/pharo/issues/detail?id=2327 : > Pharo image: core > Pharo core version: PharoCore1.1ALPHA #11312 > Virtual machine used: Squeak 4.2.4beta1U (Mac) > Class browser used if applicable: Â Browser > > Steps to reproduce: > 1. Click System->Software Update > > 'Error: can''t find EOCD position' > -- > View this message in context: http://n4.nabble.com/Error-when-Loading-11313-Pha-CleaningCompilerTests-tp2… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 19, 2010

Re: [Pharo-project] Fonts for dummies

by Henrik Sperre Johansen

On 19.04.2010 21:16, Schwab,Wilhelm K wrote: > I'm not sure how to read "it's not the kerning you are looking for." Read it as "if you meant kerning in the sense that the width of a string ~= width of each individual character" i.e., the ascent/descentKerns in StrikeFonts are not used for this. > What I am trying to discover is how to get the exact pixel size of '0xFFFF' and of 'suffix AV' - the latter will potentially involve more kerning than the former. When rendered by StrikeFonts, no, they will not, since it does not do kerning. For FreeTypeFonts, #widthOfString:from:to: does exactly what you ask. It wouldn't be impossible to add kerning to StrikeFonts, but it's a fairly major task as you'd need to: - Update the StrikeFont class to include kerningInfo, and implement kerningLeft:right: method - Define font construction methods etc. - Actually define useful kerning values for fonts in use. - Update the displayString: primitive to take into account kerning info Basically, the support is just not there at all at the moment for StrikeFont kerning. Cheers, Henry

April 19, 2010

[Pharo-project] Thrift servers in Pharo (help needed)

by Yoandy RodrÃguez MartÃnez

Hello everyone: As you may have noticed, Thrift doesn't generate Smalltalk server code. I've added some of the missing classes for server support (ported from python implementation) but my Smalltalk skills are not good enough to add server-side code into the generator. Is anyone interested?

April 19, 2010

Re: [Pharo-project] Fonts for dummies

by Henrik Sperre Johansen

On 19.04.2010 21:17, StÃ©phane Ducasse wrote: > On Apr 19, 2010, at 9:10 PM, Schwab,Wilhelm K wrote: > >> That will take some (re)reading, but is much appreciated. The fact that the Canvas is not involved is deeply discouraging: one should not have to edit a class method in order to involve a higher-resolution output device :( > which method? > open a clear bug entry or request for improvement > Stef It's not a class-method, it's a setting, set by f.ex: TextStyle pixelsPerInch: 72. (Try changing it to something other than 96 while using a FreeType font somewhere, and you can see the text size changing) Ideally there'd be code which gathers this value from the system at image startup, I'm not aware if such code exists though. Cheers, Henry

April 19, 2010

Re: [Pharo-project] we need help for rome

by John M McIntosh

On 2010-04-19, at 12:12 AM, StÃ©phane Ducasse wrote: > probably :) > one coming from sophie and one coming from the repository. > We will fix that as soon as we can make it run on mac (ok we just have to add the inst var) but would be nice to have a clean > plugin but I imagine that john is stressed with the Scratch problem. > > Stef Well nothing a good night of sleep can't cure. I'm trying to build a new plugin based on the current squeaksource.com stuff. However MacPorts is busy grinding thru a build(s) for the thousand or so components to build freetype & pango & etc, since it's building a universal ppc, i386, x86_64 binary on an older G4 laptop running 10.5. Likely run for hours... -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

April 19, 2010

Re: [Pharo-project] Fonts for dummies

by Henrik Sperre Johansen

On 19.04.2010 21:10, Schwab,Wilhelm K wrote: > That will take some (re)reading, but is much appreciated. The fact that the Canvas is not involved is deeply discouraging: one should not have to edit a class method in order to involve a higher-resolution output device :( Please note, the "output device" in your definition, and a "Canvas" as defined in Squeak/Pharo, are two different things. A canvas does not know the physical dimensions of the display device its raster will be displayed on. Thus using it when rendering will not make any difference, but the TextStyles>>pixelsPerInch setting does what you'd like (for FreeType fonts). Repeated for clarity: > In essence, if those features are important to you: > - Use FreeTypeFonts. > - Set TextStyle pixelsPerInch: to a computed value at startup. The computed value here meaning: "Whatever you somehow manage to find out is the correct physical proportion". Cheers, Henry

April 19, 2010

Re: [Pharo-project] Fonts for dummies

by StÃ©phane Ducasse

On Apr 19, 2010, at 9:10 PM, Schwab,Wilhelm K wrote: > That will take some (re)reading, but is much appreciated. The fact that the Canvas is not involved is deeply discouraging: one should not have to edit a class method in order to involve a higher-resolution output device :( which method? open a clear bug entry or request for improvement Stef > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Johansen > Sent: Monday, April 19, 2010 9:47 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Fonts for dummies > > > On Apr 19, 2010, at 4:16 25PM, Schwab,Wilhelm K wrote: > >> >> What about what Microsoft (sorry...) calls font metrics? By involving a device context (canvas in our world), one can find out how big a particular string will be on the target device's resolution, and allowing for kerning. >> >> So far, I have found #heightOf: and #widthOf: in the Font hierarchy, which means they know nothing of the intended device, and do not (obviously anyway) seem to know about kerning. Are there glaringly missing features here, or is this simply an consequence of printing being done via PostScript and therefore still in terms of point sizes? >> >> Bill > > StrikeFonts take their glyphs from a bitmap, thus will have constant pixel sizes. (decentKern is used for italic glyphs though) As far as I know, kerning is not done for StrikeFonts, the only related use is of ascentKern when making a bitmap for italic derivatives of basefonts. > Changing StrikeFonts to include kerning info will mean rewriting the string-rendering primitive, so I wouldn't get my hopes up it is likely to happen anytime soon. > > > For FreeTypeFonts, getWidthOf: uses AbstractFont>>pixelSize, which again uses TextStyle>>pointsToPixels: , which relies on TextStyles>>pixelsPerInch. > pixelsPerInch _could_ be set based on information gathered at startup about resolution and screen size, but is not done currently, so a default of 96 is used. > FreeTypeFont>> widthOfString:from:to: returns a width which takes > FreeTypeFont>> kerning into account. (in theory, see the comment for > FreeTypeFont>> clarifications) > > In essence, if those features are important to you: > - Use FreeTypeFonts. > - Set TextStyle pixelsPerInch: to a computed value at startup. > > Cheers, > Henry > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 19, 2010

Re: [Pharo-project] Fonts for dummies

by Schwab,Wilhelm K

I'm not sure how to read "it's not the kerning you are looking for." What I am trying to discover is how to get the exact pixel size of '0xFFFF' and of 'suffix AV' - the latter will potentially involve more kerning than the former. If this were being done correctly, one would need not only the output device and the font, but also the exact text. It appears there is room to grow. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Johansen Sent: Monday, April 19, 2010 9:50 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Fonts for dummies On Apr 19, 2010, at 4:47 17PM, Henrik Johansen wrote: > > StrikeFonts take their glyphs from a bitmap, thus will have constant > pixel sizes. (decentKern is used for italic glyphs though) As far as I know, kerning is not done for StrikeFonts, the only related use is of ascentKern when making a bitmap for italic derivatives of basefonts. > Arr. Correction; the only place StrikeFonts use something with a name related to kerning is when doing something with Italics, can't remember exactly how, why, or what methods. :) In any case it's not the kerning you are looking for. Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 19, 2010

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

by Igor Stasenko

On 19 April 2010 22:04, <csrabak(a)bol.com.br> wrote: > > > > > > Em 19/04/2010 14:53, Igor Stasenko < siguctua(a)gmail.com > escreveu: > >> On 19 April 2010 20:29, Michael Haupt wrote: >> > Hi Igor, >> > On Mon, Apr 19, 2010 at 7:21 PM, Igor Stasenko wrote: >> >> Computer always 'knows' what Â next operation it going to perform, >> >> and don't need to use any precedence. >> > ... enter quantum computers. :-P >> > let me rephrase that: by Â building any machine, we using a certain >> set of Â principles, on Â which it will Â function. Â So then, Â we could >> _predict_ how it Â will behave, if we provide Â a set of instructions. > > NO. As historical counter examples there are the Neural net based computer > http://en.wikipedia.org/wiki/Perceptrons And where is a contradiction? A first two paragraphs on that page describing a principles on which it built. And then, you saying that you can't predict how it behaves after you built it using these principles? > which was built as a machine, > or the homeostat http://en.wikipedia.org/wiki/Homeostat (ditto). > > my 0.019999... > > -- > Cesar Rabak > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 19, 2010