On Saturday 29 Aug 2009 8:48:18 pm Juan Vuletich wrote:
> I'll have time for this on Monday. I guess the first thing to do is to
> understand what is the correct font for '12 point'. I mean, the correct
> ascent/descent and line grid, and the correct shape of the glyphs. Some
> specification of mean kerning / length of strings would be nice too.
In traditional typography, the point referred to the size of the metal block 
used to carve shapes (glyphs).  The size of a Point depended on 
regional/political affiliations :-). Anglo-american point was about 72.27 points 
to an inch. Not all shapes would be contained within its metal block base. 
Some (see g in the picture http://ilovetypography.com/2008/03/23/sunday-type-
bright-type/) would also extend (kern) beyond its base. String length would be 
the sum of metal block widths. The sum of shape widths in a run of characters 
could differ from the string length due to kerns.

Digital typography uses co-ordinate grids instead of a metal block. It defines 
Point (aka DTP point or Postscript point) as 1/72th of an inch. Grid size 
varies for different fonts. TTF uses grids of 512, 1024 or 2048. The point size 
used in font names are 'design size'. i.e. a modern 12pt TTF contains glyphs 
drawn inside a 2048x2048 grid that will *look like* a 12pt metal typeface when 
scaled to various digital canvases like a 96dpi screen or 1200 dpi printer. 

Though we continue using the term 'glyph' (carving), images are computed on 
the grid using a 'pictal' process and then scaled to the target canvas. A 
Truetype font is actually a bytecode program interpreted by a font engine 
(e.g. Freetype) to scale glyphs at run time. Internally, glyphs are defined in 
terms of lines and curves in a grid (called em-square) of size 512, 1024 or 
2048. Given a canvas (dpi, depth), a glyph code and a point size "hint", the 
font engine will scale a glyph and tweak them using 'hints' expressed in 
bytecodes. For instance, stretching a '(' vertically may scale only the middle 
part and leave the tips alone. The o in "xo" will slightly overshoot x for 
good visual flow.

However, aesthetic rendering requires a context and a run of characters. The 
spacing between one character to the next is dictated by kern and direction. 
Sometimes, adjacent glyphs may coalesce into a more compact or even different 
shape (e.g. ffi) called a ligature. Runs are handled by a text rendering engine 
(e.g. Pango, Qt, ghostscript). Of course, the ligated glyph shape should exist 
in the font.

Squeak's text printing algorithms only consider boxes and kerns - no 
ligatures, no hyphenation, no direction. Building a true multilingual layout 
engine is a non-trivial task. Mac and Wintel have only one shaping engine 
while Linux has multiple options (Pango, Qt, ICU, m17n, Graphite). Pango and 
Qt are widely used. Squeak should be able detect and load shaping engines on 
the fly on Linux or allow command line options to pick a wrapper plugin.

There is also the blue plane approach proposed in FoNC paper - treat text 
boxes like graphic objects. A Font engine is just a specialized vector graphic 
editor that avoids intensive geometric computations by caching precomputed 
shapes in a glyph table. Allow graphic objects to have class level editors. 
Then when a glyph is missing for a character code, open a glyph editor and 
allow a new shape to be defined on the fly or imported from a public font 
definition file. Beats displaying $?.

Subbu