April 2010 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Fonts for dummies

by Schwab,Wilhelm K

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 :( 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

April 19, 2010

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

by csrabak＠bol.com.br

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 which was built as a machine, or the homeostat http://en.wikipedia.org/wiki/Homeostat (ditto). my 0.019999... -- Cesar Rabak

April 19, 2010

Re: [Pharo-project] Zoomable UI

by Igor Stasenko

On 19 April 2010 21:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > igor > > do you think that we got have a svg canvas: as a merge between what you show us at Brest -- with the tiger and using the rome cnavas -- having a dedicated subclass for svg. > Well, the problem is, that the above frameworks putting us into a constraints. While, we can do things like that (http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html) ourselves, without using 3rd party stuff. I know, it sounds like NIH syndrome, but i am concerned, that using rome or svg we will be able to render a 10 browser windows on a desktop with 25 frames/second rate. The above stuff may be fast enough, when you updating only a portions of the display surface (like currently Morphic does and optimized for that). But things like zoom-in or zoom out, obviously require a full desktop update at each frame, so we need a framework which can support a decent frame rate for this. This means, that such framework should not rely on a techniques/optimizations, which require updating only a portions of screen, but instead, its throughput should be high enough to redraw a full screen each 1/25 second. > Stef > > On Apr 19, 2010, at 7:32 PM, Igor Stasenko wrote: > >> This is where, i think we should be heading: >> >> http://ahead.com >> >> And this is why i think, a graphics frameworks should be vector based, >> not a pixel based one. >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

April 19, 2010

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

by csrabak＠bol.com.br

Em 19/04/2010 14:21, Igor Stasenko < siguctua(a)gmail.com > escreveu: > On 19 April 2010 19:40, Michael Haupt wrote: > > Hi, > > On Mon, Apr 19, 2010 at 4:26 PM, Igor Stasenko wrote: > >> I am serious. If you can't learn the simplest syntax rules, you > >> can't learn anything else. > > but Syntax, dearest Igor, is key! And Note The Capital "S"! > > You see, Lisp clearly sucks because it has too many > > brackets. Python and Haskell are most unfavourable because they > > have whitespace with semantics. Pascal, Modula-2, and Ada are way > > too verbose. Forth organises programs in pages - now *that* is > > bureaucratic and old-fashioned, aye? Smalltalk obviously doesn't > > know how to compute with natural numbers properly. Smalltalk, > > Self, and Io share the indignity of not even having proper > > keywords. Java, Scala, C, and C++ ... don't even get me started, > > man: curly braces are sooooo 80s. Erlang does not end sentences > > with an exclamation mark, it puts it in their midst - how messy, > > bah. In Prolog, you have to write your own rules, which makes it > > seem as if the language didn't have any: yuck! > > If you consider all these points wisely, you will inevitably come > > to the conclusion that the only language with a proper, clear, > > civilised, and tidy syntax out there is brainfuck. Some argue it's > > unacceptable due to its name, but that is not a syntactical > > argument and hence invalid. I win. > > > I agree. all languages having bright and dark sides. And people > free to choose what they like (or not). > I wonder, how a computer languages would look like for europeans, > if they are first were invented by Chinese or Japanes cultures. ( > you know, they would use glyphs in it ;). I could not be totally positive on this, but I think the better proxy we have for that is APL which used some special symbols and even needed a special keyboard for it! -- Cesar Rabak

April 19, 2010

Re: [Pharo-project] Zoomable UI

by StÃ©phane Ducasse

igor do you think that we got have a svg canvas: as a merge between what you show us at Brest -- with the tiger and using the rome cnavas -- having a dedicated subclass for svg. Stef On Apr 19, 2010, at 7:32 PM, Igor Stasenko wrote: > This is where, i think we should be heading: > > http://ahead.com > > And this is why i think, a graphics frameworks should be vector based, > not a pixel based one. > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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] Zoomable UI

by StÃ©phane Ducasse

Yes! if you ask me I would have loved that Squeak develops such vision and pharo deals with the low level ugly bits. This would have been a clear win-win situation... Stef On Apr 19, 2010, at 7:32 PM, Igor Stasenko wrote: > This is where, i think we should be heading: > > http://ahead.com > > And this is why i think, a graphics frameworks should be vector based, > not a pixel based one. > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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

[Pharo-project] [Job] Smalltalker needed at Zurich

by StÃ©phane Ducasse

Dear Smalltalkers :) > Dear Sir/Madam, > > Iâve been referred to you by one of your members. Iâm currently looking for a Smalltalk Developer to work for an Investment Bank in Zurich. The initial contract is for 12 months with the likelihood of staying there for about 3 years. They are looking for people with recent experience of Development in Smalltalk and who have experience of Gemstone also. The role is to start in the coming months. If you know anyone currently looking for opportunities or people who would be interested, I would be most grateful if you could forward my details. > > Kind Regards, > > Danny Shaw > > > Kind Regards / Freundliche GrÃ¼sse / Meilleures salutations > > Mr Danny Shaw > Consultant â Europe IT Division Recruitment / Arbeitsvermittlung > Nicoll Curtin Limited > Tel: +44 207 397 0135 > Email: danny.shaw(a)nicollcurtin.co.uk > My LinkedIn Profile: > http://www.linkedin.com/in/dannyjshaw > > Please consider the environment before printing this e-mail > > LEGAL DISCLAIMER > The contents of this email and any transmitted files are confidential and intended solely for the use of the individual or entity to whom they are addressed. We hereby exclude any warranty and any liability as to the quality or accuracy of the contents of this email and any attached transmitted files. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please contact the sender and delete the material from any computer. Nicoll Curtin Technology Limited is registered at the address above, in England & Wales, under number 04704369. >

April 19, 2010