Now that you know how to create a Multiple Master setup and keep your outlines compatible, it is time to determine your instances. As it so happens, we have prepared a step-by-step tutorial for you.
Okay, so we have set up our masters for interpolation, and then, we made sure the paths in our glyphs are compatible. Now it is time to determine our instances. Each instance will be one font in the font family we are about to generate.
Setting up instances
Okay, let’s get this done. Go to File > Font Info > Exports and add instances via the Plus button at the bottom left: Pick Add Instance for Each Master and/or simply Add Instance. Glyphs will then insert instances with the same values as the defined masters, or simply a Regular instance with default values:
Now, there are three super-important fields in an instance. Firstly, the style name, displayed in the text field labeled Name, must be unique for each instance. Choose your style name wisely, because a lot depends on it. You can use uppercase and lowercase letters, even space. But for better compatibility, it is a very good idea to only use ASCII characters for the style name.
Then, take a look at the Weight popup right below the name. At first sight, this may seem like a redundant repetition of the Style Name field. But it is not, because it determines the little grey number next to it, which in turn determines the font menu order, at least in Adobe applications.
And, most importantly, there’s the Interpolation value for Weight. Remember the stem widths we used as Master values? In our example, it was 100 and 250. The weight interpolation value must be a number in between. In other words, whatever number you put in here will be the stem width of this font! Cool.
So, let us add a few instances with the Plus button in the lower left corner of the window. Then, we should make sure, each of them has its own style name, weight class, and an interpolation value between 100 and 250 in this example, or whatever your master stem values are in your font.
Then go back to an Edit tab in the main window, open the Preview section by (1) clicking on the eye icon in the lower left corner of the window, then (2) pick an instance from the popup menu next to it. Resize the preview area by dragging the separator line. The preview will center on the current glyph, but you can click and drag the preview horizontally to any other position:
Or, even better, simply export into the Adobe Fonts folder, and all fonts will be available immediately in InDesign or any other running Adobe app. Cool.
Again, do not install the exported fonts in the system, e.g., with Font Book or a third-party font manager, in order to avoid font cache trouble.
Keep your style name short
One good piece of advice: Keep your style name as short as sensibly possible in order to avoid problems in Windows. How short? Well, you are on the safe side if the combined length of family and style name does not exceed 20 characters by much. If the name is too long, Windows may think the font is invalid. We have had conflicting reports, but 29 characters seems to be a hard limit for the Family Name, and sometimes combined lengths of less have caused problems already. The only way to find out is to test-install it in Windows. If you get an error like this, consider shortening family and/or style name:
But sometimes, you will not be able to keep it short enough. Imagine a style name like
Condensed Ultralight. Unless you have a very, very short family name, you will run into problems. In cases like this, use shortened versions of the parts that make up the style name. For instance, use
Cd for Condensed,
Xt for Extended,
Lt for Light,
Rg for Regular,
Md for Medium,
Sb for Semibold,
Bd for Bold,
Hv for Heavy,
Bk for Black,
Ultra, etc. Then, add a custom parameter called Typographic Subfamily Name, and set its value to the long version of the name. This is going to be the name that will actually be displayed in the user interface. Speaking of which, you can also shorten the family name, and use a Typographic Family Name parameter for the unabridged version of the family name.
Take control of font menu ordering
As I mentioned above, the Weight Class popup below the name determines the order in the font family submenu, at least in Adobe applications. But how? Well, it does so by changing the number associated with a certain weight, which can range from 1 to 1000. Look closely:
In a nutshell, smaller number equals lighter weight equals higher position in the font menu. On a side note, and to make things more complex, the Width Class one row below does the same thing, but takes precedence over the weight class. But if we only employ a weight axis, that is not really important.
There is a potential pitfall here, though. Some of the options in the popup value lead to the same weight class number:
- ExtraLight, Thin, UltraLight: 250
- Light: 300
- Normal, Regular: 400
- Medium: 500
- DemiBold, SemiBold: 600
- Bold: 700
- UltraBold, ExtraBold: 800
- Black, Heavy: 900
So, what if we have two very light weights, lighter than Light (300), in other words: what if we want to differentiate between Thin and UltraLight? The default weight class value is 250 in either case, so the font menu order is undetermined. Easy. Simply type a better number to overwrite the value in the combo box. For example, 100 for Thin, 200 for Ultralight, or 750 if you need that extra step between Bold and Extrabold.
You may have wondered why, by default, the lightest weight classes start at 250 rather than 1, or 100. You may think that it makes no sense to sacrifice a quarter of our spectrum if we need to differentiate between many weights. And yes, I wholeheartedly agree with you. It makes no sense. The answer is somewhat embarrassing, actually. It is a leftover of a workaround for a bug in legacy versions of Microsoft Windows (I believe all versions prior to Windows 7 were affected, but I may be wrong about this). In those long-gone dark days, the Windows renderer used to artificially bolden renderings for fonts with a weight class lower than 250 by superimposing a slightly shifted duplicate of the font. 🙈 No, I am not making this up. A Hairline at weight class 100 would display bolder than a Regular at weight class 400. The semi-official reasoning behind this was that such light fonts would be too hard to see, so they had to be rendered ‘bolder’, but the double rendering just turned any light font into gibberish on the Windows screen. The only lasting effect it had was that it scared type designers and font manufacturers into starting their weight classes at 250, as a workaround for this rendering failure in Windows. However, modern versions of Windows do not do this anymore, so you can safely start your weight spectrum at lower values like 100 now. But what about backwards compatibility, you ask? Well, for whom? It is unlikely that someone who insists on still running Windows XP will shell out a dime for purchasing your font, so you can safely ignore that market segment. And you do not want to offer unpaid support for hardware and software that is older than most people reading this tutorial. Come on, really.
Okay, we know how to pick a spot on the interpolation axis. But how do we know what is a good spot? Assuming we have a Light and a Bold Master, and we use their values for the Ultralight and Heavy instances, then where exactly between those two should we put the Light, Regular, the Medium, the Semibold, the Bold instances?
As a first step, it may appear to be a good start to distribute them evenly, so the difference between two subsequent weight values is always the same. E.g., your Light Master is at 20, your Bold Master is at 140. Then the instance values would be: 20, 40, 60, 80, 100, 120, and 140. The difference between two instances is always 20. We call this a linear distribution of stem weights, or simply, equal steps. But, alas, it doesn’t work that well:
There is too little difference between the instances in the middle of the spectrum. And unfortunately, this is where it counts most. They just look too similar, I couldn’t tell which one is supposed to be the Regular, the Book, or the Bold. Clearly, we need better interpolation values.
Enter interpolation theory. It was the great Luc(as) de Groot who noted that it is not the absolute difference that counts, but rather the stem growth percentage. In the above example the first step, between 20 and 40, is an increment of 100%. The the second step, between 40 and 60, only of 50% anymore. The percentages gradually decline until the end, where, between 120 and 140, we count an increment of merely 16.67%. In search of a better solution, De Groot himself suggested to keep that growth percentage constant (at least for vertical stems). This has become famous as the Luc(as) Formula or the Luc(as) distribution. According to this, the relative visual difference stays the same, whereas the absolute difference is small at first, but grows larger towards the end of the spectrum:
Certainly an improvement. The worst thing you can say about it is that there are too many light weights. Big deal, we’ll just leave out one, or we could just make one step less in total. And OK, let’s admit it, the jump between the two boldest weights is a pretty big one. But still, the last three weights would make a good set of Regular, Semibold, and Bold. Does it always work that well?
No, says the incomparable Pablo Impallari. He thinks that if you interpolate from very thin to very bold, the Luc(as) distribution causes steps to become too large at the bold end of the axis. In other words, from what looks like a Semibold, it immediately jumps to what most people would perceive as a Heavy. We could easily fit another instance in there.
In other words, if the interpolation spans from very much white and very little black (Light) all the way to very little white and very much black (Heavy), then we need smaller steps towards both ends of the axis. After all, a small step at the beginning may already cause the stem to double, and a small step at the end may cause the little white counters to be cut in half. So, at the beginning, we need a distribution that is more like the Luc(as) distribution, and at the end, we need something that looks more like a linear distribution. Mathematicians would calculate a so-called ogee curve between those two distributions. In type design land, this has become known as the Pablo distribution:
In other words, Pablo Impallari’s curve is a step-by-step interpolation from Luc(as) to linear distribution. You can use the Insert Instances script, which is part of the Masters scripts in the mekkablue script collection. The script will directly insert the instances in the Instances tab of your Font Info window.
Whichever method you choose, please see it as a starting point. The mileage varies greatly between different designs. In the end, let your eye decide the precise distribution of stem weights.
No Grid for Light Weights
Especially Hairlines, Thins, and Lights suffer from grid-snapping to integer coordinates. One unit may already be a lot for a thin weight, and cause distortions when the overlaps are removed and the resulting nodes are grid-fitted. So, if you do have very light instances in your interpolation, consider disabling forced integer coordinates by setting File > Font Info > Other Settings > Grid Step to zero. Or better yet, disable it only for light instances in File > Font Info > Exports by adding a custom parameter called
Grid Spacing to their respective Custom Parameters field. Set its value to zero and you are done:
Important note: the finer grid will export to OpenType/CFF fonts, i.e., fonts with PostScript outlines. Glyphs saves them with an .otf suffix. Be advised that there is software that has problems with a finer coordinate grid. In particular, PDF creation that involves Quark XPress and some old printer drivers (e.g. BR-Script drivers) have issues with decimal coordinates and may show a little dent in each path, in the area of its respective starting point.
OpenType/TT fonts, i.e., fonts with TrueType outlines, do not have that feature in the first place, and coordinates will be rounded in all .ttf fonts.
Phew, now we deserve a coffee break.
Update 2013-12-14: Removed a usage note for the Insert Instances script, because it is not necessary anymore in its latest version.
Update 2015-07-20: Updated for Glyphs 2.
Update 2018-11-10: Updated screenshots, added screenshots for previewing in Edit view and the Grid Spacing parameter, reformulated section about naming, added warning about font installation and link to font cache tutorial.
Update 2020-01-17: first adaptations for Glyphs 3, rewrite imminent.