On 13 September 2013 00:43, tim Rowledge <tim at rowledge.org> wrote:

>
> On 12-09-2013, at 3:30 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>
> >
> >
> >
> > On 4 September 2013 03:21, tim Rowledge <tim at rowledge.org> wrote:
> >
> > On 02-09-2013, at 12:45 PM, tim Rowledge <tim at rowledge.org> wrote:
> >
> > > Who, if anyone, is maintaining the FreeType package? Who, if anyone,
> is using it? It has some rather old methods that nastily over-ride more
> recent methods in the trunk image. That implies it is moribund to me.
> >
> > Well it certainly sounds like nobody cares about FreeType. I guess that
> means nobody will mind as I rewrite some of the low-level font/scanner code
> and almost certainly break FreeType.
> >
> >
> > (sorry for being late on topic)
> >
> > In Pharo, we certainly do. But FreeType code also needs a decent review
> and cleanup for sure.
>
> Most code does; little code ever gets one.
>
> Amen.


> > The freetype packages is an integral part of pharo base image, and
> maintained there.
> > As for its plugin, i even managed to fix a bug recently in it.. in
> primitive which nobody uses though..
> > mainly because i had plans to use it, but i haven't time to play an
> experiment, yet. (i am still thinking
> > , maybe naively, that FT rendering speed can be improved).
>
> Probably the smart thing is to use whatever the best, most fastidiously
> maintained library with the widest platform spread. Go for something that
> makes good use of GPUs. If FreeType is that, it's worth the pain. Probably.
> Just make sure it runs on ARM based machines from the get-go or it will
> become irrelevant within a few years. Intel is being eaten alive.
>
>
AFAIK, Esteban was managed to build FT2 library on iOS.. and can use it in
iOS VMs
so, from that perspective, i think, it is safe choice.
As for GPUs & stuff: even, if you don't use FT2 library for rendering, but
just for reading the font(s) data
and extracting all necessary info (like char/glyph mappings, kerning and
glyph metrics + outlines)
that functionality alone, is good/heavy enough reason to keep using it.

>
> > Concerning MultiCharacterMeetPainfulDeathWhenStaringAtIt ... it just
> impossible to do something with it,
> > especially considering that it used for rendering text, and if you
> break/change  it , you won't be able to fix it
> > (because the image is using the very same code which you just broke to
> render all text.. ).
> > At least in Pharo, we decided to not even try to do something about it
> (and as far as i know, nobody tries
> > to do anything for years), instead we decided to write things from
> scratch,and when it will be ready, throw
> > all this out without a bit of regret.
>
> Oh you wimps! Where is the fun in that? If it doesn't involve quantum
> transforms via irrational phase-space dimensions while reciting Vogon
> Poetry in Klingon then it isn't difficult enough.
>
>
Well, if there would be any hope that it can be shaped into something more
or less ugly (instead of horrifying),
i would be all hands for it. The main issue is that code has a lot of
assumptions about font(s) and laying the
glyphs in many places.. and things are heavily optimized to render first
256 characters by old primitive (which doesn't works btw)
Freetype fonts can't use that primitive, only raster fonts can..
 other assumptions about how fonts are rendered and by what.. a lot of
these concerns is mixed in
single place.. so i do not see a solution there.
We decided to go more radical way in Pharo: we build a new text model
(replacement for Text class)
and new layout and rendering engine for it. (oh and if you think it is less
difficult than dealing with old
code, i afraid i must upset you ;).
Text domain is inherently complex.


>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: BW: Branch on Whim
>
>
>
>


-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130913/ee9db54f/attachment.htm