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