On 12.10.2012 14:42, Igor Stasenko wrote:
On 12 October 2012 13:41, Tudor Girba <[email protected]> wrote:
Hi,
Athens would indeed be great. And I am happy that this investment has high
priority in the team. But, I think for the usages that I see, we would need
font support. Is there any progress on this front?
Font support is there. I currently working on Morphic rendering (see
screenshot) and getting VMs for all 3 platforms Athens-ready.
As i said previously, don't expect Athens to support raster fonts. It
doesn't makes any sense.
With athens, you can always render number of glyphs into bitmaps and
draw them as bitmaps later, if you want it,
but i wouldn't call it 'font support', it is bitmap support. :)
For Cairo backend i did integration with freetype (which already in
pharo as you know), which means that you can
render any scalable fonts.
And if you may know, freetype package supports embedded fonts (i.e.
font data loaded from memory),
which means you don't even need to have a separate font file along the
image, you can keep font in image itself.
As for amount of memory, needed to hold truetype font in image:
we did a small experiment with Camillo few days ago , we took single
font (Deja Vu sans mono),
and edited it to have only ascii character set (0..127). The resulting
font file size is just 30Kb!
Now compare it with following:
(StrikeFont allInstances collect: [:each | each glyphs bits sizeInMemory ]) sum
1504444
1.5 Mb of bitmap data for only single raster font with couple fixed sizes.
For same size, you could have 1500/30 = 50 various vector fonts (if
only ascii character range of course).
25 then, StrikeFonts cover all of latin1 range :)
How is the rendering performance compared to Bitmap and FT fonts done
without athens/cairo?
Bitmapped FT fonts were somewhat of a hog both memory and
performance-wise iirc, due to the combination of sub-pixel accurate
glyph bitmap cache and glyph-by-glyph rendering...
Impressive progress!
Cheers,
Henry
