free: Kernagic b2
Kernagic is an Open-Source (semi-)automatic spacing tool for UFO font data (UFO can act as a superset of other formats, and tools like FontForge (guide for installing under Mac OS X) can be used for converting to and from it). It provides ways to interactively preview global and local changes to the horizontal metrics. So, the spacing can be manually altered in Kernagic, or the glyphs can be adapted to the rhythm in the font editor, if applicable. The spacing determined in Kernagic can be stored into the UFO ﬁle in question, of course.
The application is intended to be modular, so any programmer familiar with C and a minimum of GTK+ can explore their own methods. The internals of Kernagic can express kerning but the currently implemented methods only produces spacing.
The development of Kernagic started in Madrid at the Libre Graphics Meeting 2013, when Øyvind ‘Pippin’ Kolås decided to hack around the automatic font-spacing challenge. There, Dave Crossland introduced him to Frank E. Blokland’s PhD research, published partly on this website. The initial ‘averaging’ approach that Pippin explored (described in the Interactivos 13 Book was later discarded, in favour of an approach of stem rhythm placement that is based on –but at the end deviates from– Blokland’s theories. This can be found in the Snap gap method. The forenamed deviations are a point of discussion between Pippin and Blokland, and the program is now further developed in cooperation with Frank Trampe, known from the FontForge development. BTW, Kernagic has to be pronouced ‘Kemagic’ (Pippin’s idea behind this is that the ‘rn’ combination can be mistakenly read as ‘m’).
Below the three various spacing methods implemented in Kernagic to date are listed.
Shows the original spacing of the font, (includes fast switching between the original spacing and newly created ones using the F1, F2, or F3 keys).
An additional option is available here to proportionally scale the existing side bearings.
Currently provides a ﬁtting that assumes that the glyph-structures of the selected font are related to Italian and French Renaissance text type (think of Jenson, Griffo, and Garamont). Because the units are distilled from the font in question, the method works for typefaces that don’t have similar proportions, but which are morphologically related, i.e., that handle the (overshoot of the) lobes in a similar way as the prototype cutters did. So, it works also for for instance typefaces that have ‘goût-Hollandais’ proportions, like DTL Fleischmann. Consequently it will work for typefaces like Times (New Roman) and Plantin too, of course. And everything in between.
Spacing is deﬁned in cadence-units, using a predeﬁned table. The user can subsequently adjust the values based on the morphological differences between the model used for the table and the font in question. An internal table is referred to by default; this one also comes with kernagic as a text ﬁle, which be can be adapted and extended using a text-editor. A user-deﬁned table can be directly selected also.
Please note that the next edition of the application should be able to recognize for instance whether the selected font is a serifed or sans-serif typeface. Also the curve-ﬂattening should be recognized, i.e., the degree of overshoot of the round letters in comparison with the ‘stem’ letters (so, for the Jenson-model basically the largest and for the textura-model the smallest [one can explore this with the DTL LetterModeller application below]). Subsequently the most appropriate table should be automatically selected. The user should be able to save the corrections he made into a new table. And yes, there will be tables for italics too. Another point of consideration is the resolution of the cadence grid (and subsequently the reﬁnement of the tables).
This means that the program should be able to recognize for instance whether the font is a serifed or sans-serif typeface. Also the curve-ﬂattening should be recognized, i.e., the degree of overshoot of the round letters in comparison with the ‘stem’ letters (so, for the Jenson model basically the largest and for the textura model the smallest). Subsequently the most appropriate table should be automatically selected. The user should be able to save the corrections he made to a new table. And yes, it will include tables for italics too. Another point of consideration is the resolution of the cadence grid (and subsequently the reﬁnement of the tables).
An updated version of the default hard-coded table be can be downloaded here. A version for sans-serif fonts will become available shortly.
3. Snap gap
This methods permits specifying a desired gap between left and right rhythm points of glyphs. The bearings indicated by the gap is also snapped to grid in such a manner that the advance of the glyphs is a multiple of the snap value. The snap-gap method relies on automatically detected rhythm points, if the rhythm point detection works poorly with your font, or you want to override spacing decisions, one can insert one’s own rhythm points by clicking within the x-height of the glyph to change in the preview; rhythm point overrides are saved in the individual glyph ﬁles. Clicking below the x-height of a glyph removes custom overrides; clicking above it inserts a single rhythm point to be used for both left and right sides of the glyphs.
free: DTL LetterModeller 5.0
LeMo is a ﬁrst step towards the automation of type design processes, based on the underlying models for grapheme systems. Sliders can be used for the parametrized altering of the letterforms. The modiﬁed letters can be saved in the BE format and further processed in the included sophisticated glyph editor, and exported as OpenType CFF and TTF, and also UFO font ﬁles. BE and UFO ﬁles can be imported in LeMo 5. The development of LeMo is part of my PhD research, as described on this site’s homepage.
The LetterModeller (LeMo) application is also a research tool for investigating (the relation between) grapheme systems, harmonic systems (subdivided in harmonic models), proportional systems (subdivided in proportional models), relational systems, and rhythmic systems (see also: 1.1.1 Notes on systems and models). It focuses on the grapheme systems capital, book-hand minuscule, and cursive minuscule (not built-in yet) in use since the Italian Renaissance, and the morphologically related book-hand minuscules from the late Middle Ages (textura and rotunda, to be precise). The current version of LeMo does not support the ﬂexible pointed pen, but this is a matter of time.
Notes on the applied construction methodes
LeMo combines the primary harmonic model (phm) with heart (skeleton) lines for constructing letters (see also: 5.1 Notes on the construction of letterforms). Heart lines are used to deﬁne the proportions of capitals, and a vector can be applied for tracing these lines. The Humanistic minuscule is the result of the canalization of letterforms by (angle and shape of) the broad nib, so with exception of the letters k, s, v–z, which ﬁnd their origin in the capitals, these letters are constructed using the phm. Also the ‘spectacle-shaped’ g is not part of the phm.
The capital-derived letters can be either constructed using the secondary harmonic model, which is a tweaked form of the phm, or by implementing heart-line constructions for these letters. When the ﬂexible pointed pen came in vogue the eighteenth century, the heart line was distilled from the phm for applying the contrast-ﬂow of the ﬂexible pointed pen (not implemented yet).
In LeMo the proportional relation between the capitals and minuscules is pre-ﬁxed, but this relation can be altered by changing the heart-line IKARUS font though. The generic skeleton forms of the capitals can be replaced by any other mono-linear descriptions. Also it is possible to supersede any letters of the harmonic models by deﬁning skeleton forms for these.
The skeleton font can contain all characters in the ASCII range (see also the Read Me ﬁle that comes with LeMo). In case of an overlap with the characters that are constructed using the harmonic models, the characters in the skeleton font will supersede these. The height of the capitals is related to the ascender height; when the length of the ascenders is changed, the height of the capitals will be changed accordingly. The basis for this relation, i.e. the starting point for the transformations, is deﬁned by the relation between the capitals and the phm when applying a certain range of parameters. One way to deﬁne this relationship is to reduce the pen-width for both the phm and the capitals to a heart line. This relation can for instance be like Claude Garamont applied in his Parangon Romain, which is shown in the illustration (for which the Adobe Garamond Premier was used) below.
Currently the skeleton font has to be in the IKARUS format and (also for the moment) the name is hard-coded and should be ‘skeleton.ik’, otherwise the ﬁle will not be recognized. For the Windows version the skeleton font should be placed in the current working directory, i.e. where the program executable resides. On the Mac, the ﬁle is expected to reside in one of the application’s sub-directories, namely in …/phm.app/Contents/MacOS/.
Skeleton fonts can be constructed using DTL IkarusMaster (light), or with any other font (Bezier) editor and subsequently converted by DTL IkarusMaster (light) to the IK-format. Because the construction of the serifs is related to that of the primary harmonic model, serifs cannot be added to the skeleton font using the applicable radio buttons. Exceptions to the parameters cannot be applied to the skeleton font either (for the moment).
LeMo includes an outline editor, which makes glyph editing possible after exporting the font data, has been added. Glyphs can be exported in the EPS and SVG formats from the glyph editor. Basically this editor is identical to the one in DTL OTMaster, so the applicable part of the OT Manual can be used for reference.
The ﬁtting of the letters in LeMo is done via the cadence-units system (see: 3.3.1 Notes on patterns and grids).
As mentioned, LeMo is also an attempt to come to a parametrized form of type design, which, because of the built-in descriptions of the capitals and minuscules, doesn’t require any input from the user other than parameter settings. In this it completely differs from all other attempts in this direction. I have no doubt that it will be possible to develop a tool, which will completely interactively generate fonts at the end.
If something can be deﬁned, it can be programmed, in my opinion. There will be two hurdles to take though: ﬁrstly it will be necessary to have a detailed description of personal patterns and structures, i.e. idiom, in relation to the underlying generic letterforms, and secondly such a development will require a lot of resources. At the end it should be possible to generate fonts in a certain style with speciﬁc settings for the proportions, contrast and weight.
It deﬁnitely will take quite some time before this is possible, and until that time LeMo can be used to generate generic letterforms with all forenamed settings except for the idiom. For the moment the type designer will have to apply his personalized patterns and structures in a font editor.