October 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Re: Removing default fonts

by Antony Blakey

On 20/10/2008, at 7:45 PM, <bryce(a)kampjes.demon.co.uk> <bryce(a)kampjes.demon.co.uk > wrote: > I'd vote for the latter too, imagine you want to do a quick VM > experiment and you're not used to building VMs for that platform. But is that a good enough reason to retain all of the other font machinery? What cost in complexity is it worth paying so that someone not used to building VMs can do quick VM experiments? Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 A priest, a minister and a rabbi walk into a bar. The bartender says "What is this, a joke?"

Oct. 20, 2008

Re: [Pharo-project] Re: Removing default fonts

by bryce＠kampjes.demon.co.uk

Michael Rueger writes: > Antony Blakey wrote: > > > > On 20/10/2008, at 10:48 AM, John M McIntosh wrote: > > > >> Well for one thing it requires then implementing the freetype plugin > >> on the iPhone, so it's a barrier to entry for VM developers who are > >> dealing with platforms that may or may not > >> have freetype on them to enable the running of a pharo image. > > > > In that is the case, then I think a stated requirement for Pharo should > > be a list of platforms, or an explicit statement that it must be usable > > without FreeType. > > I would vote for the latter. > > I would vote strongly against leaving out Squeak's "native" text > rendering. With Squeak native I mean a method to render text without any > external libraries, e.g. for systems like SqueakNOS, bare metal systems etc. I'd vote for the latter too, imagine you want to do a quick VM experiment and you're not used to building VMs for that platform. Requiring TrueType to use your image will raise the bar significantly. Asking for TrueType to deliver a nice look is fine. Bryce

Oct. 20, 2008

Re: [Pharo-project] Re: Removing default fonts

by Antony Blakey

On 20/10/2008, at 5:34 PM, Michael Rueger wrote: > I would vote strongly against leaving out Squeak's "native" text > rendering. With Squeak native I mean a method to render text without > any external libraries, e.g. for systems like SqueakNOS, bare metal > systems etc. How would you justify that in relation to a goal or principle? Maybe: "Pharo must be usable for bare metal systems" or "Pharo must not depend on any libraries that don't come with the OS". In the first case you obviously need *some* external support. Maybe a definition could be driven by the API requirements of the any underlying platform. In the second case you would need to specify the particular OS/version combinations that are targeted. Either of those seem better than "no dependence on FreeType" because they are less arbitrary. > What needs to be done is a proper refactoring of the text, font and > text style system so the different rendering mechanisms are easily > interchangeable and transparent to the programmer. Sure, but that's somewhat orthogonal to my point. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 When I hear somebody sigh, 'Life is hard,' I am always tempted to ask, 'Compared to what?' -- Sydney Harris

Oct. 20, 2008

Re: [Pharo-project] Re: Removing default fonts

by Michael Rueger

Antony Blakey wrote: > > On 20/10/2008, at 10:48 AM, John M McIntosh wrote: > >> Well for one thing it requires then implementing the freetype plugin >> on the iPhone, so it's a barrier to entry for VM developers who are >> dealing with platforms that may or may not >> have freetype on them to enable the running of a pharo image. > > In that is the case, then I think a stated requirement for Pharo should > be a list of platforms, or an explicit statement that it must be usable > without FreeType. I would vote for the latter. I would vote strongly against leaving out Squeak's "native" text rendering. With Squeak native I mean a method to render text without any external libraries, e.g. for systems like SqueakNOS, bare metal systems etc. What needs to be done is a proper refactoring of the text, font and text style system so the different rendering mechanisms are easily interchangeable and transparent to the programmer. Michael

Oct. 20, 2008

Re: [Pharo-project] Re: Removing default fonts

by Antony Blakey

On 20/10/2008, at 10:48 AM, John M McIntosh wrote: > Well for one thing it requires then implementing the freetype plugin > on the iPhone, so it's a barrier to entry for VM developers who are > dealing with platforms that may or may not > have freetype on them to enable the running of a pharo image. In that is the case, then I think a stated requirement for Pharo should be a list of platforms, or an explicit statement that it must be usable without FreeType. I'm making two unrelated points: 1. Who not use only FreeType and/or native metrics/rendering. I'm not talking ATSUI, just the kind of simply metrics and character rendering that Squeak has now i.e. char widths, kerning pairs, no ligatures, no bidi etc). 2. Have a clear specification of Pharo's target/constraints/ requirements/intended users/use cases/task applicability, next to the manifesto. What existing code/packages must continue to run? What features must be retained? > Although the iPhone does have freetype buried somewhere on it, I'm > not sure if this is a one hour change or will take all week to > enable it. Would it matter if it were a week? Wouldn't the simplification of that part of Pharo be a worthwhile tradeoff? In the scope of a 3 year project, this would seem a simple decision. Or, alternatively, use a metrics/rendering system that uses the native API, with a fallback to FreeType, which IMO would be better, and would work in the iPhone. IMO a clearer statement of goals and constraints would enable better decision making and targeting of effort. Maybe 99% of the problem is Morphic, and a quicker solution would be a native control interface ala SWT. For the purposes of the tools, esp OB, this might be a better outcome for the same effort (OB uses very few controls), especially if the purpose of Pharo is a better Smalltalk playground, rather than an improved Morphic playground. One strategy (which I am following) is to improve OB, get all tools into OB (sans Workspace/Transcript), and then move OB off Morphic. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Nothing is really work unless you would rather be doing something else. -- J. M. Barre

Oct. 20, 2008

Re: [Pharo-project] Re: Removing default fonts

by John M McIntosh

On Oct 19, 2008, at 3:51 AM, Antony Blakey wrote: > Stef, > > On 19/10/2008, at 8:30 PM, StÃ©phane Ducasse wrote: > >> yes but this is still important that we keep the solution to not >> rely on TT fonts > > > Why is that? Well for one thing it requires then implementing the freetype plugin on the iPhone, so it's a barrier to entry for VM developers who are dealing with platforms that may or may not have freetype on them to enable the running of a pharo image. Although the iPhone does have freetype buried somewhere on it, I'm not sure if this is a one hour change or will take all week to enable it.

Oct. 20, 2008

Re: [Pharo-project] Simple TODOs posted on bugtracker

by StÃ©phane Ducasse

good idea! Stef On Oct 19, 2008, at 8:46 PM, Marcus Denker wrote: > Hi, > > I posted some TODO items on the bugtracker. Some are very simple to > solve: > > http://code.google.com/p/pharo/issues/list > > Marcus > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 19, 2008

Re: [Pharo-project] Simple TODOs posted on bugtracker

by Marcus Denker

On 19.10.2008, at 21:07, Dan Corneanu wrote: > Is there a way of filtering them other then searching for the TODO > word ? > you can search the lable "Task" instead: http://code.google.com/p/pharo/issues/list?can=2&q=label%3ATask Marcus > On Sun, Oct 19, 2008 at 9:46 PM, Marcus Denker <denker(a)iam.unibe.ch> > wrote: >> Hi, >> >> I posted some TODO items on the bugtracker. Some are very simple to >> solve: >> >> http://code.google.com/p/pharo/issues/list >> >> Marcus >> >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> >> _______________________________________________ >> 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 19, 2008

Re: [Pharo-project] Simple TODOs posted on bugtracker

by Dan Corneanu

Is there a way of filtering them other then searching for the TODO word ? On Sun, Oct 19, 2008 at 9:46 PM, Marcus Denker <denker(a)iam.unibe.ch> wrote: > Hi, > > I posted some TODO items on the bugtracker. Some are very simple to solve: > > http://code.google.com/p/pharo/issues/list > > Marcus > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 19, 2008

[Pharo-project] Simple TODOs posted on bugtracker

by Marcus Denker

Hi, I posted some TODO items on the bugtracker. Some are very simple to solve: http://code.google.com/p/pharo/issues/list Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 19, 2008