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

Re: [Pharo-project] Fonts for dummies

by Henrik Johansen

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

April 19, 2010

Re: [Pharo-project] Fonts for dummies

by Igor Stasenko

On 19 April 2010 17:16, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Hello all, > > What is the best way to create/access fonts? Â So far, TextStyle defaultFont seems to work. Â I was about to write that I was feeling lost otherwise when I recalled setting fonts by name in Migrate, and a comment therein reveals that I stole some preferences from Lukas who used LogicalFont. Â Perhaps specifying the family name following his example (with cues from exploring LogicalFont all) is the answer? > > 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? > I think there is a _glaringly missing features here_. The fonts in squeak seems evolved from being a simple raster bitmaps, and don't quite well resembling a functionality beyond this. > Bill > > > > > _______________________________________________ > 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 Henrik Johansen

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 kerning into account. (in theory, see the comment for clarifications) In essence, if those features are important to you: - Use FreeTypeFonts. - Set TextStyle pixelsPerInch: to a computed value at startup. Cheers, Henry

April 19, 2010

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

by Igor Stasenko

On 19 April 2010 16:53, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > You are missing the point: I *agree* that supporting precedence rules would very likely be bad and I would probably argue against any such change. Â Where you are doing damage to us all is by ridiculing someone who is raising a valid concern rather than debating that person with reasoned arguments. > I am serious. If you can't learn the simplest syntax rules, you can't learn anything else. And i don't care about what such people thinking, because they will never try to think different. They are found that moving in direction where crowd moves, is a best way. Its not interesting to them, if there are other directions, and some even doesn't interesting in what direction they are currently moving. They are told to move in that way and they moving. Fine. Let this mindless crowd go its way. I don't feel a loss. > Bill > > -- Best regards, Igor Stasenko AKA sig.

April 19, 2010

[Pharo-project] Fonts for dummies

by Schwab,Wilhelm K

Hello all, What is the best way to create/access fonts? So far, TextStyle defaultFont seems to work. I was about to write that I was feeling lost otherwise when I recalled setting fonts by name in Migrate, and a comment therein reveals that I stole some preferences from Lukas who used LogicalFont. Perhaps specifying the family name following his example (with cues from exploring LogicalFont all) is the answer? 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

April 19, 2010

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

by merlyn＠stonehenge.com

>>>>> "Schwab,Wilhelm" == Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> writes: Wilhelm> Lack of precedence *is* a weakness of the language and Wilhelm> ridiculing someone who cites it won't help anything. Until you're able to reframe it as a problem of familiarity. Sure, most people learned programming (and algebra) with precedence rules. But precedence is not inherently the most natural thing. And this is what you must make clear. Look at the contortions that happen when you have a language that has either user-defined operators (prolog comes to mind) or just a hella lotta levels (Perl has 40 levels of precedence). The point is that you *cannot*, even as a reasonably intelligent human being, parse such languages *locally* to tell what the order of ops are. You *must* consult something external, which can be pretty crazy if it means hunting through source code instead of just looking it up on a ref card. Smalltalk's way is very simple. Sure, it's not optimized for the most common case (multiplication over addition), but it's optimized for *all* the other cases. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

April 19, 2010

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

by Schwab,Wilhelm K

Sig, You are missing the point: I *agree* that supporting precedence rules would very likely be bad and I would probably argue against any such change. Where you are doing damage to us all is by ridiculing someone who is raising a valid concern rather than debating that person with reasoned arguments. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Monday, April 19, 2010 8:41 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released! On 19 April 2010 15:20, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Lack of precedence *is* a weakness of the language and ridiculing someone who cites it won't help anything. Â IMHO, the best response we have is that consistency is among Smalltalk's great strengths, and arithmetic precedence was and remains a deliberate casualty of that design goal. Â I am not saying we should change the situation, but grant the point. > > If the other side is not willing to accept an extra set of parentheses here and there in the name of consistency, you might subsequently try pointing out that a nice mix is to do logic, memory management and GUI implementation in Smalltalk and to do number crunching in C++ with the functions exposed as extern "C". Â Not only is it faster than a pure-Smalltalk solution, the equations translate much as one exects, and C's memory management woes are largely irrelevant. > > Precedence was indeed a pain to learn as a child, but we all did learn it, and the best of us will at times get bitten when the compter does not "know" those same rules. Â The trick, is to respectfully challenge people to try this wonderful system that is nice enough on balance to get people to re-think arithmetic - or at least pitch it that way. > the thing is, that smalltalk expression a+b*c not necessary related to arithmetics. I could create own class with #+ and #* selectors which can do anything i want, doing things way different to be any kind of math. Also, in a school terms, a precedence rules is defined for very small set of operators, while in smalltalk we could define a new one at any time using binary selector syntax. Now imagine, that each time you creating a new operator, you must a) define its precedence b) remember how to use it. Now think, how hard it would be for someone to read your code and understand the semantics, since he doesn't knows what precedence you are defined for new operator(s). Another problem that if you defining a new operator and its precedence, a precedence tends to be globally applied. Now what you would do, if you filing in the code, in which a precedence for some operators doesn't matching the precedence of those, which already in image? Also, mathematicians using different kinds of algebras for different domains, and defining different and weird looking operators in that algebras. So, that's why i think its completely pointless to even think about supporting precedence rules in smalltalk, by breaking its uniform and _simple_ syntax rules. > Bill > > > -- 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] [Pharo-users] [ANN] Pharo 1.0 released!

by Igor Stasenko

On 19 April 2010 15:20, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Lack of precedence *is* a weakness of the language and ridiculing someone who cites it won't help anything. Â IMHO, the best response we have is that consistency is among Smalltalk's great strengths, and arithmetic precedence was and remains a deliberate casualty of that design goal. Â I am not saying we should change the situation, but grant the point. > > If the other side is not willing to accept an extra set of parentheses here and there in the name of consistency, you might subsequently try pointing out that a nice mix is to do logic, memory management and GUI implementation in Smalltalk and to do number crunching in C++ with the functions exposed as extern "C". Â Not only is it faster than a pure-Smalltalk solution, the equations translate much as one exects, and C's memory management woes are largely irrelevant. > > Precedence was indeed a pain to learn as a child, but we all did learn it, and the best of us will at times get bitten when the compter does not "know" those same rules. Â The trick, is to respectfully challenge people to try this wonderful system that is nice enough on balance to get people to re-think arithmetic - or at least pitch it that way. > the thing is, that smalltalk expression a+b*c not necessary related to arithmetics. I could create own class with #+ and #* selectors which can do anything i want, doing things way different to be any kind of math. Also, in a school terms, a precedence rules is defined for very small set of operators, while in smalltalk we could define a new one at any time using binary selector syntax. Now imagine, that each time you creating a new operator, you must a) define its precedence b) remember how to use it. Now think, how hard it would be for someone to read your code and understand the semantics, since he doesn't knows what precedence you are defined for new operator(s). Another problem that if you defining a new operator and its precedence, a precedence tends to be globally applied. Now what you would do, if you filing in the code, in which a precedence for some operators doesn't matching the precedence of those, which already in image? Also, mathematicians using different kinds of algebras for different domains, and defining different and weird looking operators in that algebras. So, that's why i think its completely pointless to even think about supporting precedence rules in smalltalk, by breaking its uniform and _simple_ syntax rules. > Bill > > > -- Best regards, Igor Stasenko AKA sig.

April 19, 2010

[Pharo-project] [CfP] DLS'10

by Pascal Costanza

Dynamic Languages Symposium 2010 October 18, 2010 Co-located with SPLASH (OOPSLA) 2010 In cooperation with ACM SIGPLAN John Ascuaga's Nugget, Reno/Tahoe, Nevada, USA http://www.dynamic-languages-symposium.org/dls-10/ ***** Call for papers ***** The 6th Dynamic Languages Symposium (DLS) at the conference formerly known as OOPSLA is a forum for discussion of dynamic languages, their implementation and application. While mature dynamic languages including Smalltalk, Lisp, Scheme, Self, Prolog, and APL continue to grow and inspire new converts, a new generation of dynamic scripting languages such as Python, Ruby, PHP, Tcl, and JavaScript are successful in a wide range of applications. DLS provides a place for researchers and practitioners to come together and share their knowledge, experience, and ideas for future research and development. DLS 2010 invites high quality papers reporting original research, innovative contributions or experience related to dynamic languages, their implementation and application. Accepted Papers will be published in the ACM Digital Library. Areas of interest include but are not limited to: * Innovative language features and implementation techniques * Development and platform support, tools * Interesting applications * Domain-oriented programming * Very late binding, dynamic composition, and runtime adaptation * Reflection and meta-programming * Software evolution * Language symbiosis and multi-paradigm languages * Dynamic optimization * Hardware support * Experience reports and case studies * Educational approaches and perspectives * Object-oriented, aspect-oriented, and context-oriented programming === Submissions and proceedings === We invite original contributions that neither have been published previously nor are under review by other refereed events or publications. Research papers should describe work that advances the current state of the art. Experience papers should be of broad interest and should describe insights gained from substantive practical applications. The program committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality. Accepted papers will be published in the ACM Digital Library. Papers are to be submitted electronically at http://www.easychair.org/conferences?conf=dls2010 in PDF format. Submissions must not exceed 12 pages and need to use the ACM format, templates for which can be found at http://www.acm.org/sigs/pubs/proceed/template.html. === Important dates === Submission of papers: June 1, 2010 (hard deadline) Author notification: July 15, 2010 Final versions due: August 13, 2010 DLS 2010: October 18, 2010 SPLASH/OOPSLA 2010: October 17-21, 2010 === Program chair === William Clinger, Northeastern University, Boston, Massachusetts, USA === Program committee === Robby Findler (Northwestern University) Jeffrey S. Foster (University of Maryland) Lars Thomas Hansen (Adobe Systems) Charlotte Herzeel (University of Brussels) S. Alexander Spoon (Google) Eric Tanter (University of Chile) Jan Vitek (Purdue University) Alessandro Warth (Viewpoints Research Institute) [to be completed] -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium

April 19, 2010

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

by Schwab,Wilhelm K

Sig, Lack of precedence *is* a weakness of the language and ridiculing someone who cites it won't help anything. IMHO, the best response we have is that consistency is among Smalltalk's great strengths, and arithmetic precedence was and remains a deliberate casualty of that design goal. I am not saying we should change the situation, but grant the point. If the other side is not willing to accept an extra set of parentheses here and there in the name of consistency, you might subsequently try pointing out that a nice mix is to do logic, memory management and GUI implementation in Smalltalk and to do number crunching in C++ with the functions exposed as extern "C". Not only is it faster than a pure-Smalltalk solution, the equations translate much as one exects, and C's memory management woes are largely irrelevant. Precedence was indeed a pain to learn as a child, but we all did learn it, and the best of us will at times get bitten when the compter does not "know" those same rules. The trick, is to respectfully challenge people to try this wonderful system that is nice enough on balance to get people to re-think arithmetic - or at least pitch it that way. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Sunday, April 18, 2010 11:07 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released! On 16 April 2010 13:10, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Apr 15, 2010, at 10:33 31PM, Adrian Lienhard wrote: > >> Thanks, Daniel, for posting on reddit! We currently are almost at the top of the list... >> >> >> Cheers, >> Adrian > > Gotta love reddit... > 3 most repeated/discussed topics in comments: > Â - "I don't know what Smalltalk is, and the site doesn't tell me, not even the about page!" > Â - "SUCKS, I can't use my favourite text-editor and git!" > Â - "1 + 2 * 3 = 9 WTF SMALLTALK" > Oh yeah.. there are two guys battling to the death, each defending own point.. The guy who claims that precedence rules is a must, must be forgot, how much pain it was took to learn them in a childhood :) > :D > > Cheers, > Henry > > > _______________________________________________ > 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. _______________________________________________ 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