All articles 51

OpenType is indisputably the font format of the present. It is cross-platform, and it is a free and open standard. It opened possibilities for smooth handling of advanced typography and better support for complex scripts.

But limitations remain. They may not be obvious if you only ever design or use Latin text faces. But when you think about what the best solutions are for complex scripts such as Arabic, you realize that there are fundamental strictures of OpenType that make things less efficient than they could be. For example, do we really have to design innumerable glyphs for ligatures, conjuncts, and contextual variants when these are all combinations of simple building blocks? Here is a previous thread on the subject:

Critiques of the OpenType format?

So for a while, I have been thinking about what could be improved in the future font format that will replace OpenType. I don't think it is too early to start brainstorming about just what we want to see. So here are some ideas I had about the future font format:

  1. Parametrizable outlines

The idea is that the points and handles of outlines could be defined as equations, not just absolute coordinates. This covers everything that can be handled with Multiple Master fonts, such as weight, optical size, x-height, etc. that apply globally to the entire font, but does not stop there. Serifs of the "v" could be pulled in according to context, and an "fi" ligature could be widened harmoniously in accordance with tracking. Something like the Arabic Tatweel, a horizontal line segment used to stretch characters in an Arabic text when setting metal type and carried to the digital age, will be rendered obsolete as we gain the power to stretch any part of any glyph by any amount we desire.

This is something that Metafont explored, but Metafont as a software never really caught on, because defining a font full of parameters simply wasn't worth the trouble for Latin type designers. Worse, Metafont uses pen strokes, which is a horrible idea if naively applied to type design. The usual filled-path approach is possible with Metafont, but I have a feeling many type designers were too turned off by the pen-stroke approach to give Metafont a chance, perhaps without realizing that you don't have to use it.

Once a single instance of a Multiple Master font has been generated, or once a Metafont has been converted to a usable font format, no further parametrization is possible. But the future font format will interact with the future text engine to make full use of its parametrizability.

  1. Take component handling to the next level

The current model of font handling does not stray far from the paradigm of the glyph, most often representing a single character, as the basic unit of a font. You can assemble a glyph from components, as is often done for adding accents, but this could be made more powerful.

Each Arabic character, for example, may be more efficiently viewed as being made of simple components arranged dynamically according to context. Different components may be selected according to where the character appears initially, medially, or finally; their dimensions and positions may also be adjusted according to context. As I understand it, Thomas Milo's groundbreaking work in Arabic typesetting with ACE and Tasmeem, which produces complex and natural designs with a simple architecture, is based on analyzing Arabic typography down to sub-character-level components—why not build such powerful component handling into the font format itself?

My main motivation, however, is in handling hangul, the Korean alphabet. Despite hangul being an alphabet made up of two dozen basic letters, a hangul font needs thousands of glyphs, one for each hangul syllable, because of the way the writing system is organized around syllabic blocks. If we include archaic or non-standard syllables, then the number of glyphs needed becomes untenable. The consonants and vowels that make up a hangul syllable can each have a number of shape variants, and need to be fine-tuned in size, shape, and position to fit together harmoniously. This is why I would like to see parametrizable outlines and more powerful component handling.

I have a (very) long-term personal project of designing hangul fonts using programming tools to apply the idea of automatic selecting the right shape variant, size, and position and to shape each syllable intelligently, but this is just a way of automating the design process. When I generate the font, it will still require thousands of glyphs, and it will still not support every conceivable syllable combination. A font format that can put together hangul syllables dynamically out of a small set of components will not only be much reduced in file size but also be unlimited in the syllables it can represent.

  1. Flexible spacing and positioning paradigm

I owe this idea to this previous thread.

The idea of each glyph occupying a fixed rectangle is a leftover from the days of type in physical metal. This inevitably introduces problematic combinations, which are currently tackled through kerning, which is just a digital analogue of physical kerning. Many people have thought that there must be a more efficient way to achieve good spacing than going through endless kerning pairs, and some ideas were offered in the thread. I haven't given this issue enough thought, but it's something to think about for the future font format.

* * *

You can probably see that supporting all these features requires a sophisticated text engine as well as a new font format, not to mention all the support needed from OS and application developers. Usable tools will have to be developed in order for people to be able to design fonts that support these features. I cannot imagine just how much work it will take to implement all this. Applications are still catching up on supporting OpenType, after all.

We would be entering whole new levels of complexity, perhaps just to introduce features that most casual designers of Latin typefaces will have little need for. I myself can't really justify something like implementing parametrizable outlines for anything other than hangul or possibly Chinese (it would be nice to have for Latin, but there really isn't much that can't be done with alternate glyphs). So realistically, I don't expect much enthusiasm for such an undertaking.

I really think however that something like this will be necessary and desirable at some point, when there is more demand for more natural text processing for complex scripts and more computing power is available for sophisticated text engines. This is not to say that OpenType will become obsolete; it should be perfectly possible to maintain backwards compatibility just like today's OpenType-savvy software supports previous formats like TrueType.

What are your thoughts about these ideas? What would you look for in the font format of the future?

Is there anything odd in the calt list of Vista/Windows 7's font "Segoe Script"? I was alerted today by an InDesign user that contextual alternates do work for Latin script, but don't appear to get activated for Cyrillic text.

I examined the OTF tables, and, sure enough, the calt tables for Latin are only defined in the Latin Script part, and the Cyrillic Script section has its own calt list. Nothing out of the ordinary, I presume.

Theoretically, the used program ought to recognize a series of Cyrillic characters and automatically switch over to the Cyrillic section -- right? I think that was the entire purpose of the Scripts sections. Could it be an error in InDesign CS4? Or am I misinterpreting the use of the Script tags and how they would work in practice?

From the 1st of July till 21 September the latest edition (3.7) of DTL OTMaster will be offered with a 50% discount on the standard licensing price of €255.

Version 3.7 contains a lot of new functionality. From the import/export of Ideographic Variation Sequences (IVS) to the editing of feature parameters, and from an autohinter for edited or newly added glyphs to support for COLR+CPAL tables. One can read about all details in Karsten Lücke’s wonderful manual.

Some use OTM for font-spelunking, other use it for Open(Type)-heart surgery. Some use it for compiling OpenType Layout features (directly in the font, or exported for proprietary workflows) by applying the elegant automatic subsetting, while others use it for instance for mark (to mark) positioning. OTM is the ultimate Swiss (or actually German/Dutch) knife for CFF- and TTF-based OpenType, TrueType, and TTC (TrueType Collection) fonts.

A complete listing of the functionality in OTM 3.7 can be found here. DTL OTMaster can be ordered directly with forenamed discount at DTL’s FontTools shop or at FontLab Ltd.


Anybody know a way of programming a font so that it remembers you've typed a letter, and the next time you type that letter an alternate glyph is used? This would be useful in distressed fonts. Ligature substitution is ok for double letters but if I type a word like 'dada' say, and I want to make sure the distressed look isn't repeated, it doesn't help.

I have a feeling it should be simple enough to do this - somehow get typing a letter to flick a switch and then if the same letter is typed while that switch is on, substitute an alternate glyph then reset the switch.

Any ideas?


I'm making a big multilingual sans serif and by default, the "a" and the "g" are double storey. I do include the single story versions available by "salt" because this feature works virtually everywhere, where there is Opentype).

However, I've heard that the Germans mostly use the single story g. I've searched pictures of various street signs in Germany and Austria and I haven't found any double story g's.

Would it be ok to include 'locl' feature for German language to substitute only the g (while leaving the "a" double story)? I do understand that the single story g has its roots in Fraktur. And is it a German-only preference or the neighbour languages like Dutch, Danish, Swedish, etc. look more natural with a single storey g?

In the attachment, there's an example with single and double storey g's. To my eyes, the combination of single story g and double story a looks more "natural" in a German text. Don't look at the kerning, I didn't start polishing it yet.

| Attachment | Size | | --- | --- | | GermanG.PNG | 65.55 KB |

Former Typophile moderator Zara Vasquez-Evens has written an interesting article on Medium (, prompted by the recent petition for a better user interface for accessing OpenType features in design software (

A few selected quotes:

What the sh*t is a Stylistic Set? Most of the discussions and UI mock-ups floating around of proposed UI solutions that I have seen, seem to be created by type designers, for expert users, i.e., people who know a thing or two about font technology. While every idea is valuable, there is a fundamental UI component that seems to be overlooked and that is nomenclature. There are differences in the language that type designers speak and the language that the broader design community speaks.> How are we planning to educate people on the complexities of font technologies and the features available to them? How can type designers and advocates for great typography better inform the general population on how to take advantage of a font’s potential?> We need tools that are dynamic, context-sensitive, and smart.

I, for one, would welcome a completely visual solution.

I'm prototyping a cursive font where, at least on paper, any word with a "t" in it has the crossbar on the t extended to the left and right over letters as long as this fits; verticals in h, l, d, etc. will cut off the bar, so something like:

becomes something like:

I'm not entirely sure how to implement this, though. I was thinking of using many-to-many GSUB rules based on glyph classes, but no matter how I look at it, it turns into needing recursive GSUB behaviour...

1) t [low] ->[t with bar that continues right] [low with left-connecting overbar]
2) [low with left-connecting overbar] [low] ->[low with fully connecting overbar] [low with left-connecting overbar]
3) [low with left-connecting overbar] [high] -> [low with fully connecting overbar] [high with lef-connecting overbar stub]

and rule 2 would have to recursively kick in... and that's just in one direction.

Has anyone every tried something like this before? Or does anyone have thoughts on how this might be achieved?

Dave Crossland informs about new tool:
"ttfdiet (TTF DIacritics Encoding Tool) applies a “diet” to a .ttf font: it modernizes the way in which glyphs for precomposed Unicode characters are stored in a TrueType-flavored OpenType font, and reduces the font's file size." [from]

I installed Behdad Esfahbod's FontTools and wrote diet.bat file:

python c:\ %1 pause

  • be sure Python (2.6 or higher) is installed and added to the PATH
  • "c:\" it is where file is stored
  • there is no output font file name, so ttfdiet will create ttf file, with .diet added, in the path where input font file is stored
  • "pause" let me to see what will happen

It works perfectly. Fonts were tested in BabelPad and FireFox 32.0.3 (winXP sp3). See FireFox:

I don't care the file is smaller, important is that errors are clearly visible (I marked some with red circles). I belive font will be better when "diet-proof" or "diet-ready".

A new version of DTL OTMaster (OTM), the highly sophisticated tool for reviewing, editing, and altering tables and glyphs of fonts with a SFNT-file structure, has become available since today. OTM is a must-have for professional font developers. To quote Adam Twardoch, product and marketing manager at Fontlab Ltd.: ‘OTMaster works with surgical precision: it will only modify the portions of the font that the developer wishes, leaving all other structures unchanged. This makes OTMaster a great companion to any font editor and an indespensable element even in the most complex OpenType font production workflow.

Version 5.0 contains a range of additional functionality, among which:

— New powerful Text Viewer, which includes Harfbuzz for the interpretation of OpenType Layout features. It contains a nice three-state features selector (on / default / off).
— Support for all the competing color OpenType font extensions: Microsoft’s ‘COLR’/‘CPAL’, Adobe’s ‘SVG’, Apple’s ‘sbix’, and Google’s ‘CBDT’/‘CBLC’.
— Updated Font Viewer, containing now a search field for glyphs, unicodes...
— Updated Side by Side Viewer, which contains among other new options, a ‘Winding fill’ as opposed to the standard fill option.
— Enhanced and now fully mature Glyph Editor (basically a compact version of DTL FontMaster), with improved guideline and grid functionality, improved measurement options, new clipboard with support for multiple entries, etcetera, etcetera.

DTL OTMaster 5.0 is available for Mac OS X, Windows and Linux. Please note that because of the inclusion of Harfbuzz the lowest supported Mac OS X version is Lion (instead of Snow Leopard in case of version 3.7) now.

From today on until the 6th of January 2015, OTM 5.0 can be purchased with a special 25% Christmas-holiday discount. Current 3.7 licensees are eligible for an upgrade against € 7.50 administration and handling costs. FontLab Ltd. customers can do this via FL Ltd.’s website and DTL customers can apply for this via DTL’s FontTools shop. Registered users owning any other previous versions can upgrade for € 50.

DTL OTMaster can be purchased directly from FontLab Ltd. and DTL’s FontTools shop (web adresses are mentioned above).

So, as a sort of oddity I'm adding fists/manicules to my latest typeface and I figured arrows would be handy as well. Now, I have them mapped with the appropriate unicodes as far as possible. To make them more accessible I figured I would create a stylistic set so you can type >> to make an arrow. However, when I add the code and I click on compile OpenType program it tells me it has to abort because of errors.

I must be doing something wrong. How do you usually map these kind of symbols to OT functions, or don't you?

feature ss07 { # Stylistic Set 7
sub > > by arrowright;
sub < < by arrowleft;
sub > > > by blackmaniculeright;
sub < < < by blackmaniculeleft;
} ss07;

If I generate an OTF font, and I have a glyph created for onehalf, will "1 slash 2" automatically be replaced by onehalf, or do I need to build a feature for it?

Tried building a feature, but an "aborting because of errors" error:

feature frac { lookup frac1 { sub one slash 2 by onehalf; } frac1; lookup frac1; } frac;

Also, what is the easiest way to code for all "(number) slash (number)" to change into nut fractions? I'd like this to work up into the thousands (333/1028 for example). Creating a "sub" line of code for every possible fraction is obviously impractical.

I'm wondering if it's possible to script any advanced features. Primarily I'm looking to solve a specific problem, but more generally I'm curious if more can be done with OT scripting than the standard "sub" script to replace one glyph with an other.

I'm tired of people over-hyphens so I wanted to script a fix for that, so in the standard ligatures I put the following code:
sub comma hyphen by comma_endash;

This replaces the comma followed by a hyphen with a ligature glyph where I have a comma followed by a line which is in between the hyphen and the en dash in length, which is more appropriate for denoting prices ($50,–).

Now I want to do the same fix for "x" after numbers, so every time an /x is typed after a number it's automatically replaced by a multiply symbol. Unfortunately I'm unable to script this accordingly. Every time I try to generate the font, it aborts because of an error in the script. Now, I'm not sure if my code is appropriate for numbers. I'm trying the following:
sub one x by one multiply;

I suppose it's possible to replace 1 followed by x by a '1×' "ligature" like in the comma/hyphen example but I need the code to be much more flexible because it's not realistic to create such a "ligature" for all numbers from all number sets, and with this method it's no longer affected by tracking. So is there a way to define that the /x is automatically replaced by the multiply symbol when preceded by a number? If I can't script this for all numbers automatically, is it possible to script it for each number specifically without having to rely on the ligature method described above? Is this function possible at all?

Just a heads up, I'm running a font contest over at my blog. This weekend I'll be giving away 5 complete sets of my Jeanne Moderno fonts.

To enter, go here:

And just do what it says.

Contest ends 11 p.m. (pacific time) Saturday, January 16, 2010.

Also posted, the best of my blog from the past year.

(is it me or is this whole 2010 date thing seem so sci fi?)

Hi everybody! I am happy to announce the release of Cavatina: an experimental font for musical notation. It is the result of two years of work in design and programming.

Cavatina is my misuse (to put it nicely) of the OpenType font architecture, inspired by Travis Kochel's FF Chartwell. Similarly, the font relies on contextual alternates and ligatures to take care of the formatting and allow the support of a wide range of musical grammar. Among others, it is possible to write over four octaves of different notes, key and time signatures, barlines, accidentals, articulations as well as ornamentation, providing a system robust enough to allow fast musical composition. Additionally, I have written an open-source converter that translates the Cavatina text files to MIDI and MusicXML. A browser based text editor with integrated MIDI playback is also provided for the majority of those who don’t have a Mac.

Without any further talk, go check out the website:
To test the font you can go through the quick start. You don’t have to be a musician to understand how it works.

Tell me what you think!

Indices : Technical Info : cswh

'cswh' is an OpenType feature tag with the friendly name "Contextual Swash". Click here to read the spec from the Microsoft Layout Tag Registry.

Contextual Swashes for Beginnings
OpenType Scripts, Swash

Indices : Terminology : Case

In current practice, usage of the term case most likely refers to the use of uppercase (capital) or lowercase letters. See some examples below. In letterpress practice, case refers to the physical box (case), usually wooden, that a given set of letters is stored. Capital letters were stored in the upper (top) case and lowercase letters were stored in the lower (bottom) case.


ALL CAPS -- All letters are capitalized.

Title Case -- The first letter of each word is capitalized.

Sentence case -- where the first character is capital and the remaining words are lowercase.

Camel Case -- Also called internal caps where one or more characters in a given word (or string) has a capitalized letter. This is often used in programming languages and increasingly seen for naming or branding companies or products.

Indices : Technical Info : Feature Tags : case

'case' is an OpenType feature tag with the friendly name "Case-Sensitive Forms". Click here to read the spec from the Microsoft Layout Tag Registry.

Greek OpenType Features

Indices : Technical Info : Feature Tags : sups

'sups' is an OpenType feature tag with the friendly name "Contextual Swash". Click here to read the spec from the Microsoft Layout Tag Registry.

OpenType Superiors Feature: Why Do Letters and Numbers Have Different Baselines?

darling is a display font, with medium contrast, designed to be used in the composition of titles, letterings, visual id’s and short texts such as illustrated books or magazines for children.
it has 738 characters and a lot of opentype features that allows the composition of titles and/or words in a very different ways. otherwise, when applied with no features, it produces a homogeneous amount of text.

Trying to control quotation marks when typesetting in inDesign:

I am trying to see if I can make quotation marks change automatically for different languages. For example if I select (in InDesign) the Language drop-down menu in the character palette > my English style quotes would transform into French guillemet quotes.

I see that just by having the standard repertoire of quotes does not mean easy implementation.

Otherwise how do French or German typographers call for a specific style of quotation mark?
- Do the desired marks have to be the default in the font file?

Any help to solve this mystery appreciated.

Michael Hernan

I have made some minor changes to OpenType Features Editor, and the new version is now available here:

I fixed some issues with the autogeneration of ligature feature rules and identified some additional fixes and enhancements to pursue.

For those who don't know, OpenType Features Editor is a little tool I made to generate a features file from information in an AFM file. So you can export the AFM for a font, generate a *.fea file and import that back into your font development software. It's Windows only at the moment, but I have plans to make it available as a web-based tool as well.

Please let me know if you encounter any issues with this release or have any other feedback. Thanks!


Jabana & Jabana Alt & Jabana Extras — 52 fonts for coffee and more

In 2014 Jabana was released as just a single font. One year later, after some hard work Nils Thomsen rounded it up to a very useful and complex typeface system. Inspired by having a “Schorle” at Hamburgs bars. Super compressed to extended letter shapes in 5 widths and 4 weights – smooth handwritten marker curves and especially a wide range of opentype features define the large character set of Jabana.

Each letter and punctuation got three simple varieties of alternates. This gives a nice looking handwritten nature to the font. They will be randomly chosen by the contextual alternates feature or even by hand via stylistic set (ss01, ss02).

The whole characters for serious western european typography comes along Jabana.
Beside the standard accented letters, fractions, mathematical glyphs, superiors and inferiors you will find alternates, extra bullets, different arrows, negative figures and roman numerals.

Another reason for the amount of 1530 glyphs are the numerator and denominator letters which came from A-Z, punctuation and the extra bullets (ss09-16). They are meant to be used for decoration or distinction. Especially an opentype stylistic set gives an extra touch to it while putting a dot/line above denominators or underneath numerators (ss03+numr/dnom).

Jabana Alt is a much more standardized alternate version of Jabana.
The Jabana Alt fonts got normal uppercase proportions and a larger x-height for the lowercase.
Just in case ... If Jabana is too unique for your purpose take: Jabana Alt !

Extras! … If you need some awesome specials ... Jabana Extras will help you to realize a fast and good looking modern design ... You’ll get crazy about it, because the Extras are combinable and flexibel in width. Just switch on the ligature feature (opentype) and type from 'a' to 'z' or 'A' to 'Z'.

Arrows, Banners, Lines, Ornaments, Divider and Web or Coffee Icons … Try it, learn it, love it!
Banner: Combine for example ‘h‘ and ‘m'. Continue to type, it will get wider! Switch to uppercase it will get black! Type another letter, e.g. 'g', it changes … A good thing! It also looks nice with all other handmade fonts!

Opentype: Yes it's true! … Nils used all 20 stylistic sets to put more specials into Jabana! But no worries, the PDF shows each feature and it's effect ... There are for example options to center the 'small caps' or 'lowercase' ... choose different bullets ... get lined numerator or denominator ... But if this is too complicated, the font is still nice enough!

Naming: Jabana/Jebena is a container used to brew coffee in the Ethiopian, Eritrean and Eastern Sudanese traditional coffee ceremony. It is usually made of pottery and has a spherical base, a neck and pouring spout and a handle where the neck connects with the base. (

BUY Jabana here: (The whole families are on 75% sale until 5th of April.)
Jabana —
Jabana Alt —
Jabana Extras —
PDF specimen download: (22 pages with detailed instructions)

Ok, so I was using class based kerning and on the metrics window, everything seems to be working fine... kerning values look like they should. "Class kerning with exceptions" is enabled in the Metrics window.

However, when I open up the preview window, I see that kerning is all messed up and not working like it should (seems like class kerning is being ignored).

I tried exporting the font and I still get that.

Anyone here knows what is happening?
I spent about 10 hours kerning pairs and to know that my kerning is now not working is stressing me out big time :(



I have a font that i'd like to utilise the calt feature, and have found Thomas Phinney's article [], among others [] to be most helpful. YET I still can't get my head around writing the feature so that it creates a more 'random' outcome.

The details are:
– x3 variants for all characters
– x3 classes [00 / 01 / 02] including one of each character, 79 characters in total [A–Z, a–z, 0-9, punctuation]
– feature currently looks like:

feature calt {
lookup calt_one {
sub @set_00 @set_00' by @set_01;
sub @set_01 @set_00' by @set_02;
} calt_one;

lookup calt_two {
sub @set_02 @set_00' by @set_02;
sub @set_01 @set_02' by @set_00;
sub @set_01 @set_00' by @set_02;
sub @set_00 @set_01' by @set_02;
} calt_two;

sub @set_00 space @set_00' by @set_01;
sub @set_01 space @set_00' by @set_02;
} calt;

– the result being:

00 02 02 02 01 00 00 02 02 02 01 00 ...

  • after a 'space' the pattern resets

– I also have a fourth alternate for a handful of characters. I've not yet put them into the equation, is this something that is possible or do I have to have the same number of alternates for each character regarding this contextual random feature?

I just wondered if it's seemingly obvious what the mistake is that i'm making, and if anyone could possible help...?!



There is tables that explains which applications support different opentype features like this link:
In this table we see that all of the mentioned apps support the "standard ligatures" opentype feature.
but how would I know if I implement an GSUB LookupType 5 or 6 (Contextual substitution) in a standard ligatures it will be executed in those apps. I need a GSUB LookupType 5 or 6 to be executed by default so I think it's safe to put it in this feature and it will be executed in all of those apps, right?