Subbu,
Thanks for this excellent overview of fonts. I've never seen this topic explained clearly in one place before.
Dave
On Sun, Aug 30, 2009 at 04:13:00PM +0530, K. K. Subramaniam wrote:
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