A pixel font is a fun and easy way to get started in Glyphs Mini.

Start a New Font

First, open Glyphs Mini and select File > New (Cmd-N), to create a new font document. Next, go to File > Font Info and name your font. We’ll call ours ‘Pixelfont’, because I just woke up and can’t think of anything better. Then, at the bottom of the window, you’ll find the options for Grid Spacing. The Grid Spacing value defines how coordinates get rounded. The default value is 1, which stands for 1 unit, a thousandth of the font size. E.g. if your font size is 12pt, then 1 unit will be 0.012pt. For pixel fonts, we want all tools and all modifications to always snap to the grid, so we set higher values. This ensures that pixels in your font are automatically on the correct position. Usually, best results are achieved if the grid step value is the same as the size of the pixel. So, e.g., if you have a pixel that is 50 units wide, the grid step should be 50 as well, so we set our Grid Spacing to 50/1:

The Pixel Component

To make it extra easy for you to create a pixel font, there’s the Pixel tool in Glyphs Mini. Click and hold the Pencil tool or press Shift-Cmd-B to access the tool. But wait! Using the Pixel tool without a pixel glyph in your font will trigger a warning dialog that will also give you the option to generate a pixel glyph right away with an Add button.

Pushing the Add button will add a glyph called pixel (the Pixel tool needs this) with a square the size of your grid step, and set it to not export because it shouldn’t appear as a glyph in the finished font.

If you want to draw the pixel yourself, start with a good old square. Activate the Rectangle tool (F), and drag a square. The pixel square should be on the so-called origin point, the intersection of the left sidebearing and the baseline:

When you are drawing the rectangle, you will notice right away that the path will stick to the grid. That’s great!

Drawing Pixels

Now that we’re ready, let’s start drawing! Open a glyph you like the best by double clicking it in the Font view. To draw pixels, simply click and drag on the canvas. Glyphs Mini places the pixel glyph as a component in the glyph you’re drawing in. That way, you can be sure that the pixels are all the same.

To delete pixel components that have already been placed, click on an existing pixel, and start dragging. Now, have fun building your glyphs!

Selecting Components

Selecting a component is easy. Simply click on it with the Select tool (V). Then you can move it around with the cursor keys or your mouse.

But if you want to replicate a set of pixels, e.g., a stem or an arch, you will have to select multiple pixels. There are two ways to achieve that. Firstly, you can Shift-click multiple components after each other. This is useful for non-contiguous selections, i.e., pixels that are not next to each other. Secondly, you can hold down your Option key and drag-select a range of pixels with a rectangular selection:

Hint: When drag-selecting your pixel components, what counts is whether the origin point is captured in the selection rectangle. So, think of selecting the bottom left corner of your pixels when you drag-select.

Batch-Editing

The default glyph width is 600 units. But, well, that does not look so nice:

To start with the spacing, you can make sure all your glyphs have the same left and right sidebearings. Here’s how: First select all glyphs in Font view by pressing Cmd-A. Then, enter the values in the bottom left window. The values for your left and right sidebearing should be multiples of your grid spacing, in our case, we simply set them to 50.

Now, it is easy to make individual changes in the grey info box. But make sure you only enter values that fit our pixel grid, in other words, it must be a multiple of our grid step.

If you want to know more about spacing, read our tutorial on Spacing.

Looks much better now, don't you think?

Pixel Variants

Of course, you can play around a little with your pixel. For instance, you don’t have to make a square, you might as well use a circle. To do that, you can change the shape of your existing pixel. Because the pixel tool places the pixel as component in your glyph as you draw, all pixels will change when editing the original pixel glyph shape. You’ll notice that, when drawing a circle, it will be build to something like this:

This is because the Subdivision, the second value of the Grid Spacing, is set to 1. The Subdivision divides the grid step, so snapping happens on the grid subdivisions, not directly on the grid. If you set this value to 25, for example, your circles will look like this:

Set the Subdivision value to something that makes sense for your pixel design. For full flexibility, set it to the same value as your Grid Spacing. Feel free to experiment with your grid and pixel shape.

Export and Test Your Font

If you have complex pixels, i.e. anything but the simple square at the beginning, you have to make sure that hinting is turned off when exporting. So, when you export your file (Cmd-E), uncheck the Autohint option. Why? Hinting optimizes your glyphs for low screen resolutions, which only works with simple, boring shapes. (Read more in our tutorial about PostScript Autohinting.)

If you want to test your font, do not install it in apps like FontBook or Font-Explorer. Why? Read all about it in our tutorial on eliminating font cache problems. Do you have a version of Adobe’s Creative Suite installed? If you export your fonts into the so-called Adobe Fonts folder, they are immediately activated in Adobe apps. No restarting, no cache-emptying and no re-loading required. Activate the Export Destination checkmark, click on the Path and in the save dialog that appears, navigate to: Macintosh HD/Library/Application Support/Adobe/Fonts/. If the Fonts folder does not exist, just hit Cmd-Shift-N and create folder called Fonts (with a capital F).

For more info on that, read our tutorial on testing your fonts in Adobe apps.

In Glyphs Mini, you can also choose to export your font as a webfont. To do so, check the Webfont (WOFF) option when exporting. This way, you can display your font in a web page using HTML. Sounds interesting? Read on in our tutorial on creating a webfont.

Applying Filters

If you want to experiment a little with your font, you can try some of the built-in filters. Again, make sure you have an appropriate Subdivision value, or some filters might give you an unsatisfying result. For example, if you apply the filter Round Corners to your pixel square, you’ll get this:

Here we used the filter Offset Curve without the Make Stroke option to make our pixels bolder:

So, have fun with your pixels!

So you have prepared vector drawings in Adobe Illustrator, and want to turn them into a font. It is as easy as copy and paste, but there are a handful of details you will want to pay attention to. Read on:

Coordinate Precision

In File > Font Info, you’ll find a Grid Spacing value at the bottom of the window. If your Grid Spacing is not zero, all your coordinates will be rounded by your Grid Spacing value. If, however, you set your Grid Spacing to zero, Glyphs Mini will use floating point coordinates, and practically no rounding will occur. (OK, to be precise, you get two decimals, so a little rounding does occur.)

So, if you plan a lot of transformations after import, or if your drawings have very, very fine details, then set your Grid Spacing to 0/1. Otherwise, you usually want to keep it at 1/1. Consider scaling your vector art to the right size before importing it into Glyphs Mini.

Scale: 1 Point = 1 Unit

One point in Illustrator corresponds to one unit in Glyphs Mini. By default, one unit is a thousandth of an em. Or more precisely, whatever you have set your UPM (units per em) value to in the Font Info (Cmd-I). A full em is whatever the user sets the font size to later on.

This means that, by default, your Illustrator drawings are most likely much too small. An average x-height is half an em, i.e. 500 units. And 500 units translate to 500 points in Illustrator. That’s approximately 17.6 centimeters (almost 7 inches), just for the x-height!

It’s a good idea to already scale your drawings in Illustrator. This keeps rounding errors at later stages to a minimum, especially if your Grid Spacing is not zero. For that purpose, you may want to set your measurement units to points, if that is not the case already. You can do that by right-clicking the rulers at the edges of the window or by changing your settings in Illustrator’s application preferences.

Copy and Paste

Now, all you need to do is copy and paste your vector drawings from Illustrator into Glyphs Mini. Make sure you copy only closed paths and make sure you have the right glyph activated when you paste.

There’s one problem though. Illustrator uses one coordinate system for the whole canvas, whereas the coordinates in a font work on a per-glyph basis. Glyphs Mini will recognize coordinates that are way off and ask you if you really want that object placed out of the glyph bounds in 99.9 percent of the cases, you want to Correct Bounds:

Glyphs Mini will then align the pasted drawing either to the baseline or the left sidebearing of the current glyph, or to both, whatever is necessary to bring it back into the glyph bounds. But this may mess up things like overshoots or descenders. Turns out there’s a better way to do that.

Take Control of Positioning

In Illustrator up to version CS4, you can set an origin point by dragging the crosshair from the tiny area in the top-left corner of the window where the vertical and horizontal rulers meet. Glyphs Mini will respect the position of the origin when you paste. Illustrator’s origin corresponds to a glyph’s x=0/y=0 point, i.e. where left sidebearing and baseline intersect.

In Illustrator CS5 and above, you need to set that origin in the artboard options. Bring up your artboard palette, and pick Options from the palette menu, or double-click the artboard symbol, or double-click the artboard tool in the toolbar. You can, for instance, set the height of your artboard to 500pt and its origin to the bottom left corner:

Then you can scale and reposition your letters or symbols like this:

And what about the width of the glyph? After pasting, you can quickly fix the right sidebearing by entering its value in the grey info box. Or, you can set them all at once by selecting your glyphs in the Font tab and then entering the metrics values in the info area in the bottom left of the window.

Cleaning Up

As I mentioned in the beginning, there is much more to say about good paths, but here is a quick and easy way to correct the worst problems:

1. In the Font tab, select all glyphs (Cmd-A).
2. Choose Glyph > Add Extremes. This will insert nodes at extreme positions of path segments. If you don’t know what that means, don’t worry, do it anyway.
3. Choose Glyph > Correct Path Direction (Cmd-Shift-R). This will fix your counters and the path order inside a glyph.
4. Choose Glyph > Tidy Up Paths (Alt-Cmd-Shift-T). This will remove superfluous nodes and doubled coordinates.
5. Unless you need very high detail in your outlines, you may also want to choose Glyph > Round Coordinates which will round all your coordinates to the nearest integer.
6. If you have rather complex vectors with many (100+) nodes or many overlapping paths, consider Glyph > Remove Overlap (Cmd-Shift-O) now. This will speed up export later.

Exporting

When you are done, you can export the font. Unless you have a very regular, ‘normal’ text font, you want to export without the Autohint option.

Always choose Remove Overlap, unless you already did that at an earlier stage. Removing overlaps is a technically complex operation and requires a lot of processing power and therefore slows down export. If you find yourself re-exporting a lot for testing purposes, consider disabling this option.

For testing your font, do not install your font in apps like Font Book or Font Explorer. You will run into font cache problems when you re-export after fixing something. You can better test your font in Adobe apps with the Adobe fonts folder. Or, test your font as a webfont in a web browser, then all you need to do after re-exporting is reload the test page.

Now, you’re good to go. Have fun.

This tutorial is part 4 of a series of tutorials and therefore assumes that you have read part 1, part 2 and part 3. This is what we have so far:

#MenuTitle: Glyph Shaker
# -*- coding: utf-8 -*-
__doc__="""
Goes through all selected glyphs and slaps each of their nodes around a bit.
"""

import random
random.seed()

selectedLayers = Glyphs.font.selectedLayers

for thisLayer in selectedLayers:
    for thisPath in thisLayer.paths:
        for thisNode in thisPath.nodes:
            thisNode.x += random.randint( -50, 50 )

So far, so good. I think it is pretty easy to read through it and understand what the code does. It is not that complicated, after all. Still, I want to point you to a few aspects for keeping the oversight in your scripts. First, look at this line:

selectedLayers = Glyphs.font.selectedLayers

This is equivalent to:

currentFont = Glyphs.font
selectedLayers = currentFont.selectedLayers

The first version keeps everything compactly on one line, the second version splits the content into two lines. Performance-wise, there is not really any difference between the two. So either way is fine. However, there are a few arguments for the second solution:

• Firstly, you may want to reuse currentFont several times at a later stage.
• Secondly, debugging is easier. If there is a typo and Glyphs reports an error, it is easier to spot the mistake in short lines. Remember that error messages always report the line number. In our example, the problem could lie either in accessing the current font or in accessing its selected layers. In the first solution, you would not know which, and would have to do some searching on your own. In the second solution, the reported line number directly points you to the problematic part, and you know right away what is going on.
• Thirdly, the second solution keeps your code more legible. This will become very important when you go hunting for a bug.

Yes. Keep your code legible. You will deal with it at a later time. Or worse, you will have to ask someone else to look at your code, and then it is a very, very good idea to keep your code legible. For better code legibility, you will find many tips throughout the internets (Google is your friend), but for our purposes, always remember these things:

• Keep your variable names clear and legible. Use speaking names like currentFont rather than f or currF.
• As explained above, reserve one line per action. Do not squeeze three steps into one line.
• Move distinguishable sets of actions into functions. Avoid creating long sequences of steps, a.k.a. ‘spaghetti code’.

Functions

What? Make my own functions? We talked a little bit about Python’s built-in functions in part 2 of this tutorial, but we have not made our own functions yet. Admittedly, for our script, it was not really necessary yet.

But consider the possibility that we want to expand the script because we want to do more than just slapping the nodes horizontally. For instance, we could also rotate the glyph a little, or randomly move it up and down, or skew it, or randomly add or subtract a few extra paths. Consider our loop:

for thisLayer in selectedLayers:
    slapNodesRandomly(thisLayer)
    rotateLayerRandomly(thisLayer, 5)
    randomVerticalMove(thisLayer, 100)

Looks clean and clear, right? Not really sure what the numbers in the parentheses are about, but otherwise we’re cool: we loop through each thisLayer in selectedLayers, then we slap nodes around randomly, then we rotate the layer randomly by up to 5 degrees, and finally we randomly move the whole glyph layer up or down by up to 100 units. We have not written any code for this yet, but we can already see what we are doing, simply from looking at the function names: slapNodesRandomly(), rotateLayerRandomly() and randomVerticalMove().

So, how do we make a new function? Easy, with the def statement! A function has to be defined before it is called for the first time. So, right before the loop, we insert our function definition:

def slapNodesRandomly(thisLayer):
    for thisPath in thisLayer.paths:
        for thisNode in thisPath.nodes:
            thisNode.x += random.randint( -50, 50 )

The word after def, is the function name, in our case slapNodesRandomly. It must be followed by parentheses () which can contain variable names, so-called arguments, in our case thisLayer. The parentheses are very important, because they differentiate variable names from function names. In other words, when we refer to this function, we would not just call it slapNodesRandomly, but more specifically: slapNodesRandomly(). So everyone knows it is a function we are talking about and nothing else.

In our case, the function contains one argument, thisLayer, which refers to the value that will be passed to it. The variable is local, i.e., it only is valid and accessible inside the function. That means that the word thisLayer has a different meaning inside the function (local function variable) than outside the function (global script variable). To make this distinction more clear, some coders like to apply different variable naming conventions inside functions, e.g., myLayer instead of thisLayer.

Now, all we have to do in our loop through selectedLayers is simply call the function:

for thisLayer in selectedLayers:
    slapNodesRandomly(thisLayer)

This calls the function, and between parentheses, it passes an argument to the function, the global variable thisLayer. And the slapNodesRandomly() function does the same thing we used to have spelled out in the loop. But now, we are ready to expand our script with more functionality, and keep the oversight.

Before we do this, let’s recap. This is our current status quo:

#MenuTitle: Glyph Shaker
# -*- coding: utf-8 -*-
__doc__="""
Goes through all selected glyphs and slaps each of their nodes around a bit.
"""

import random
random.seed()

selectedLayers = Glyphs.font.selectedLayers

def slapNodesRandomly(thisLayer):
    for thisPath in thisLayer.paths:
        for thisNode in thisPath.nodes:
            thisNode.x += random.randint( -50, 50 )

for thisLayer in selectedLayers:
    slapNodesRandomly(thisLayer)

Abstraction

In the world of coding, abstraction means that you take a function and make it more configurable, i.e., fit for more purposes and applications. When we take a look at the current code, slapNodesRandomly() only changes x coordinates of all nodes by up to 50 units. We could make the function more abstract by also offering changing of y coordinates, and allowing other maximum values besides 50. Let’s do just that: First we add extra arguments into the parentheses, and while we’re at it, we also supply default values:

def slapNodesRandomly(thisLayer, maxX=50, maxY=0):

Two things to remember about this: arguments must be comma-separated, and arguments with a default value (a.k.a. ‘keyword arguments’) come after normal arguments. The default values are supplied after an equals sign.

You can still call slapNodesRandomly() the way we are used to. But you can also supply new values and override the defaults. Here are all our options when it comes to calling our function:

• slapNodesRandomly(thisLayer), because you do not need to supply keyword arguments since they can fall back onto their default values: maxX is 100, and maxY is zero.
• slapNodesRandomly(thisLayer, 100) which means that maxX is 100, but maxY still takes its value from the default zero.
• slapNodesRandomly(thisLayer, 90, 80) calls the function with 90 for maxX and 80 for maxY.
• slapNodesRandomly(thisLayer, maxY=70) skips maxX so it gets its default of 100, but sets maxY to 70. Keyword arguments can either be unnamed and in the predefined order (as in the two examples above), or named and in any order, as long as they come after the required normal arguments, in this case after thisLayer.

Of course, we still have to change a few lines to make use of the abstraction. First the line that moves the nodes randomly has to be expanded into two lines, and instead of fixed values, we insert our keyword arguments:

            thisNode.x += random.randint( -maxX, maxX )
            thisNode.y += random.randint( -maxY, maxY )

So, the complete function looks like this:

def slapNodesRandomly(thisLayer, maxX=50, maxY=0):
    for thisPath in thisLayer.paths:
        for thisNode in thisPath.nodes:
            thisNode.x += random.randint( -maxX, maxX )
            thisNode.y += random.randint( -maxY, maxY )

Congratulations, you have successfully abstracted our function. Now we can change the line where we call it:

for thisLayer in selectedLayers:
    slapNodesRandomly(thisLayer, maxX=70, maxY=70)

Now open a font you don't like, select all its glyphs, and let the script do its magic. Har har.

Affine Transformations: Shift

Now that we cleaned up the loop, it should be easy to add new functions. Let’s start with one we mentioned already, randomVerticalMove(). It should randomly move the whole glyph layer up or down. So we know we need two arguments: the layer and the maximum shifting distance. This could be the first line of our function, then:

def randomVerticalMove(thisLayer, maxShift=100):

Next thing, we need to get a random number between negative maxShift and positive maxShift:

    shift = random.randint( -maxShift, maxShift )

And now we need to apply that shift to the whole layer, including nodes, anchors and components. If you look closely on docu.glyphsapp.com, at the methods a GSLayer has, you will find a function called GSLayer.applyTransform() and it takes the six numbers of an affine transformation matrix as an argument. In case your highschool math is just too long ago, this is the meaning of the 6 numbers:

1. Horizontal scale from the origin: 1.0 (means no change)
2. Horizontal shear from the origin: 0.0
3. Vertical shear from the origin: 0.0
4. Vertical scale from the origin: 1.0
5. Horizontal shift: 0.0
6. Vertical shift: 0.0

In other words, a matrix that does nothing looks like [1, 0, 0, 1, 0, 0] and if we want to shift the layer vertically, we need to change the last number. In our case we would just have to insert our variable shift, i.e., [1, 0, 0, 1, 0, shift] is our matrix. That’s it. So the rest of our function looks like this:

    shiftMatrix = [1, 0, 0, 1, 0, shift]
    thisLayer.applyTransform( shiftMatrix )

OK, recap. Our function looks like this:

def randomVerticalMove(thisLayer, maxShift=100):
    shift = random.randint( -maxShift, maxShift )
    shiftMatrix = [1, 0, 0, 1, 0, shift]
    thisLayer.applyTransform( shiftMatrix )

And our loop is now expanded to this:

for thisLayer in selectedLayers:
    slapNodesRandomly(thisLayer, maxX=70, maxY=70)
    randomVerticalMove(thisLayer, maxShift=200)

In the last line, we call the randomVerticalMove() function, and pass two arguments: the layer we are just looping through, and the maximum shift we allow. To make it more fun, I chose 200 instead of the default 100.

Affine Transformations: Rotate

How about rotating? Sounds cool, but there is no rotation in the matrix, right? No problem if you remember your last year of math at school: rotation can be achieved through a combination of shearing horizontally and vertically plus some compensatory scaling. If you like, you can dive back into trigonometrical calculations, but I will cut the story short and give you the matrix: For rotating around the origin point by an angle a, you need the matrix: cos(a), −sin(a), sin(a), cos(a), 0, 0.

So, all is set now, right? All we need to do is calculate the angle, fill it into that matrix, and apply the affine transformation, done. Well… not quite. Remember all transformations are happening around the origin point. If we want to rotate around a better pivot point, like the center of the layer bounds, we need to shift the whole layer content onto the origin point, then rotate, and finally shift everything back to its original position. Makes sense? OK, here we go:

def rotateLayerRandomly(thisLayer, maxAngle=5):

First thing we need to do is find the center of the layer and move it onto the origin point. Luckily, the layer has an attribute called bounds, and bounds has two attributes, origin and size. Digging deeper, we find that origin has x and y as attributes, while size has both width and height. To calculate the center, we need to start at the origin point, and add half the width and half the height. This is what the following two lines do:

    xCenter = thisLayer.bounds.origin.x + thisLayer.bounds.size.width * 0.5
    yCenter = thisLayer.bounds.origin.y + thisLayer.bounds.size.height * 0.5
    shiftMatrix = [1, 0, 0, 1, -xCenter, -yCenter]
    thisLayer.applyTransform( shiftMatrix )

And the two lines after that construct the transformation matrix for shifting the layer content on top of the origin point.

Now it is time to rotate. In other words, we need to first calculate a random angle between the negative and positive maximum, then construct and apply another transformation matrix with the sine and cosine of the angle. The random number part is easy:

    angle = random.randint( -maxAngle, maxAngle )

Now, how do we get the cosine and sine for that angle? In Python, there is a module for anything beyond the most basic mathematics, and it is called math. We can import it like we imported random before, and then we can access its functions. First, we need to expand the import line to also include the math module:

import random, math

Let’s see what math has in terms of trigonometric functions. In a new Python window in TextEdit or SublimeText, or the Glyphs Macro Window, type this and run it:

import math
help(math)

And you will see a lot of output, amongst which the definitions of two functions called sin() and cos(). To narrow down the help output, run this:

import math
help(math.sin)
help(math.cos)

And you should receive this output:

Help on built-in function sin in module math:

sin(...)
    sin(x)

    Return the sine of x (measured in radians).

Help on built-in function cos in module math:

cos(...)
    cos(x)

    Return the cosine of x (measured in radians).

OK, so that means that we can run math.cos(x) and math.sin(x), provided x is measured in radians. Wait a minute, our angle is measured in degrees, so we need to convert it to radians first. Luckily, there is also a radians() function in the math module. To find out more about it, we can run help(math.radians):

Help on built-in function radians in module math:

radians(...)
    radians(x)

    Convert angle x from degrees to radians.

Phew. So, let’s continue in our rotateLayerRandomly() function. First we need to make the radians conversion, then build and apply the matrix:

    angleRadians = math.radians( angle )
    rotationMatrix = [cos(angleRadians), -sin(angleRadians), sin(angleRadians), cos(angleRadians), 0, 0]
    thisLayer.applyTransform( rotationMatrix )

Did we forget anything? Of course! We need to move the whole thing back from the origin to its original position! In other words, the reverse of what we did before:

    shiftMatrix = [1, 0, 0, 1, xCenter, yCenter]
    thisLayer.applyTransform( shiftMatrix )

But I think that’s it. Let’s recap. Here is our function:

def rotateLayerRandomly(thisLayer, maxAngle=5):
    # move on top of origin point:
    xCenter = thisLayer.bounds.origin.x + thisLayer.bounds.size.width * 0.5
    yCenter = thisLayer.bounds.origin.y + thisLayer.bounds.size.height * 0.5
    shiftMatrix = [1, 0, 0, 1, -xCenter, -yCenter]
    thisLayer.applyTransform( shiftMatrix )

    # rotate around origin:
    angle = random.randint( -maxAngle, maxAngle )
    angleRadians = math.radians( angle )
    rotationMatrix = [ math.cos(angleRadians), -math.sin(angleRadians), math.sin(angleRadians), math.cos(angleRadians), 0, 0 ]
    thisLayer.applyTransform( rotationMatrix )

    # move back:
    shiftMatrix = [1, 0, 0, 1, xCenter, yCenter]
    thisLayer.applyTransform( shiftMatrix )

I added comments for clarity. And our loop now looks like this:

for thisLayer in selectedLayers:
    slapNodesRandomly(thisLayer, maxX=70, maxY=70)
    randomVerticalMove(thisLayer, maxShift=200)
    rotateLayerRandomly(thisLayer, maxAngle=15)

And, our last recap for now, the whole script looks like this now:

#MenuTitle: Glyph Shaker
# -*- coding: utf-8 -*-
__doc__="""
Goes through all selected glyphs, slaps their nodes around, rotates them a little, and shifts them up or down a little.
"""

import random, math
random.seed()

def slapNodesRandomly(thisLayer, maxX=50, maxY=0):
    for thisPath in thisLayer.paths:
        for thisNode in thisPath.nodes:
            thisNode.x += random.randint( -maxX, maxX )
            thisNode.y += random.randint( -maxY, maxY )

def randomVerticalMove(thisLayer, maxShift=100):
    shift = random.randint( -maxShift, maxShift )
    shiftMatrix = [1, 0, 0, 1, 0, shift]
    thisLayer.applyTransform( shiftMatrix )

def rotateLayerRandomly(thisLayer, maxAngle=5):
    # move on top of origin point:
    xCenter = thisLayer.bounds.origin.x + thisLayer.bounds.size.width * 0.5
    yCenter = thisLayer.bounds.origin.y + thisLayer.bounds.size.height * 0.5
    shiftMatrix = [1, 0, 0, 1, -xCenter, -yCenter]
    thisLayer.applyTransform( shiftMatrix )

    # rotate around origin:
    angle = random.randint( -maxAngle, maxAngle )
    angleRadians = math.radians( angle )
    rotationMatrix = [ cos(angleRadians), -sin(angleRadians), sin(angleRadians), cos(angleRadians), 0, 0 ]
    thisLayer.applyTransform( rotationMatrix )

    # move back:
    shiftMatrix = [1, 0, 0, 1, xCenter, yCenter]
    thisLayer.applyTransform( shiftMatrix )

# loop through all selected layers:
selectedLayers = Glyphs.font.selectedLayers
for thisLayer in selectedLayers:
    slapNodesRandomly(thisLayer, maxX=70, maxY=70)
    randomVerticalMove(thisLayer, maxShift=200)
    rotateLayerRandomly(thisLayer, maxAngle=15)

OK, I admit that I cleaned up some more: I updated the doc string, I moved the selectedLayers assignment to right in front of the loop, and I added some comments here and there.

And you see I have been a little inconsistent when it comes to extra spaces I leave between parentheses or brackets and their respective content. It doesn’t really matter, it is a matter of coding style, and I sometimes leave extra spaces for increased legibility. But I have been accused of sloppiness because of this, so you may want to be more consistent about it than I am.

And let’s see what it does to a font: Save the script, open a font you never really liked that much, select a few glyphs, and run the Glyph Shaker script again from the Script menu. This is what happens:

Ha, cool. Experiment with the values you pass to the functions and give those fonts hell. Have no mercy.

Font names are important because they determine font menu grouping and ordering, which is crucial for the way your fonts will appear to your users. What makes it difficult is the fact that the font names are stored in six different places in the font. Or actually, a few more places. Which makes it even more complicated. Historically grown, you know.

Oh, and different apps read the font naming information in different ways. Good luck.

Family Name and Style Name

Basically, fonts with the same Family Name can be grouped together somehow in a user interface. How exactly this is done, of course, depends on the software that employs your fonts. You can set your Family Name in File > Font Info > Font > Family Name:

The individual fonts of your family need to be differentiated by their Style Name, which is set in File > Font Info > Instances. Each instance has a Style Name field. Typical style names are: Regular, Italic, Bold, Medium, Light Italic, Display Bold, Caption Italic, etc. In other words, some combination of keywords for:

• Weight: Thin, Light, Extralight, Regular, Medium, Semibold, Bold, Extrabold, Heavy, Black, etc.
• Width: Compressed, Condensed, Extended, Expanded, etc.
• Slope: Italic, Oblique, Upright Italic, Backslant, etc.
• Optical Size: Display, Text, Caption, Small

Of course, you can use any style name. If it makes sense for your design, you can also call it Felt Tip or Hatched or Outline or anything you like. Western Latin accents in the name should not cause much of a problem in modern software.

If you want some instances to have different family names than the default family name set in File > Font Info > Font > Family Name, you can add a custom parameter called familyName.

So, you would end up with a naming scheme like this:

Localized Names

For maximum compatibility, however, there is something to be said for keeping the Family Name and Style Name plain-ASCII, English, and short. If you want to go beyond that, and use non-ASCII characters (e.g., for a Japanese or Armenian or Czech name), it is a good idea to add localized names.

To localize your family name, go to File > Font Info > Font, add a custom parameter by clicking on the Plus button in the Custom Parameters section, choose localizedFamilyName from the Property pop-up, and click into the Value field for choosing the language and setting the name:

Add a custom parameter for every language in which you want the name to appear different from the default Family Name. The choice of languages is limited, because the spec was written a long, long time ago in a galaxy far, far away. It supports Icelandic and Afrikaans, it can even differentiate between Flemish and Dutch, but it does not know about Malay, Mongolian or Macedonian. Sorry about that, but there is not much we can do about it.

To localize your style name, add the localizedStyleName custom parameter to the respective fonts in File > Font Info > Instances.

You can also localize the family name in the instances, i.e., the custom parameter localizedFamilyName is also available in File > Font Info > Instances > Custom Parameters. This can be useful if you have custom family names for some instances, and need to localize those too.

While we’re at it, you can also ‘localize’ the designer name entry. How? With the localizedDesigner parameter,of course. There is also another localization entry, explained further below. See if you can find it.

Style Linking

You can set up family relationships between individual fonts with something called style linking. You can define one instance as the Bold, Italic or Bold Italic of another instance. This is pretty easy with the Style Linking section in File > Font Info > Instances. All you need to do there, is activate the Bold and/or Italic checkbox, and fill in the name of the related instance, e.g.:

With style linking, you can create so-called ‘RIBBI families’. RIBBI is short for Regular, Italic, Bold and Bold Italic. This seems a bit limiting, but its purpose is to enable the Bold and Italic buttons and shortcuts in Office software. If you do this right, you can use Cmd-B in TextEdit to switch back and forth between the Regular and the Bold, or Ctrl-I in Word on Windows for toggling between the Upright and the Italic. Adobe InDesign uses Cmd-Shift-B and Cmd-Shift-I for the same purposes, by the way.

In other words, style linking can only create a relationship between four styles, not more. Another thing to consider ist that linked styles will not be displayed in Microsoft Office font menus. Only the Regular is visible, the linked styles are exclusively accessed through the B and I buttons (or the respective shortcuts). We therefore recommend the following strategy for style linking:

• The ‘Bold’ instance is the Bold of the ‘Regular’.
• The ‘Italic’ instance is the Italic of the ‘Regular’.
• The ‘Bold Italic’ instance is the Bold and Italic of the ‘Regular’. (Careful here: not the bold of the italic or the italic of the bold.)
• All other italics are the Italic of their respective upright, e.g., ‘Semibold Italic’ is the Italic of ‘Semibold’.
• For all remaining uprights, leave these settings blank.

So, if we do everything right, our font family set up looks like this:

Pro Tip: Instead of typing the name Regular into the style link field, you can simply leave it blank. Glyphs will assume Regular in that case. One error source less.

Naming for Windows and Office Software

Microsoft Word currently focuses on Family Name and Style Name, or the WWSFamilyName and WWSSubfamilyName, if present. WWS stands for Weight, Width and Slope.

Good to know: In tech literature, Family Name and Style Name are usually referred to as Name IDs 1 and 2. The term ‘Name ID’ refers to the entries in the OpenType Naming Table, which is the way the naming information gets stored in the compiled font file. For more information, see the Naming Table specification.

Good to know: The WWS names are stored as Name IDs 21 (WWSFamilyName) and 22 (WWSSubfamilyName).

The Microsoft font menu assumes a family model where the only possible members of a font family are Regular, Bold, Italic, and Bold Italic, i.e., the RIBBI styles between which style linking is set up as described above. Anything else that isn't one of these four must be considered a separate family. Therefore, Microsoft officially recommends this naming strategy:

And so on. In other words, the Style Name (ID 2) can only ever be one of the RIBBI styles. All the other info about Weight, Width and Slope goes into the Family Name (ID 1). What you can also see, of course, is that this is very different from the table you can see further above. There are a few problems with this. It is hard to handle. You have to add an awfully high number of familyName parameters, and what’s worse, you would lose your oversight in File > Font Info > Instances, because most of the style names are the same. Also, what may be right for Word, may not be ideal for other apps, like DTP programs.

But wait a minute…

There’s good news: You don’t have to do this. Glyphs will automatically take care of this at export time. Based on your style linking info, Name IDs 1 and 2 will be set accordingly in the Windows names of the Naming Table. (That’s right, the info in the name table is stored twice, once for Mac, once for Windows. Don’t even ask why.) That is why, from here on, I will not refer to the default family and style names (as entered in Font Info) by their Name IDs, because it’s more complicated than that.

If, for whatever reason, this automation does not work, i.e., the B and I buttons in Word do not produce the expected styles, you can take control of the style mapping with a custom parameter called styleMapFamilyName. This quote from the Glyphs Handbook says it all:

styleMapFamilyName: Family name used for bold, italic and bold italic style mapping. You can use this to create subfamilies within larger font families. ‘Up to four fonts can share the Font Family name, forming a font style linking group (regular, italic, bold, bold italic – as defined by OS/2.fsSelection bit settings). Glyphs uses the entries in Style Name field and in the Style Linking section of the instance for linking the four individual weights.

Again, you will most likely not need the parameter. But just in case.

Even less useful is the localizedStyleMapFamilyName parameter, which, as the name already suggests, is the localized variant of styleMapFamilyName. If I were to bet, I would guess it has been used less than 5 times in the history of this glorious application. But then again, I am not much of a gambler.

WWS Names: Name IDs 21 and 22

The WWS names, also known as Name IDs 21 and 22, are only needed:

• if the family has style variants other than weight, width, and slope, i.e., a non-WWS axis;
• and only for those fonts that have a non-normal value for that non-WWS axis, i.e., if the style cannot be expressed purely with weight, width and slope.

Let’s suppose we want to expand our font family with optical size variants, like ‘Subhead’, ‘Display’, ‘Caption’, etc. The fonts we have seen in the tables above would not require WWS names because they are not non-normal on our new Optical Size axis. But the new fonts we add, that take up a special, non-normal position on our Optical Size axis, they do need the WWS names.

And the way this works is that you create separate families with the non-normal names, and put those family names into ID 21, but keep all the weight, width and slope info in ID 22. So, Name ID 22 is not only for RIBBI names, but for anything that falls into the weight, width or slope category, like Medium Extended Italic or Bold Condensed Oblique.

How do you do that in Glyphs? Easy. You add the appropriate custom parameters for the respective fonts in in File > Font Info > Instances. For the WWS Family Name, you used WWSFamilyName, and for the WWS Subfamily Name, you add a WWSSubfamilyName. Who would have guessed.

Note 1: Inclusion of IDs 21/22 should correlate exactly with the state of OS/2.fsSelection.bit8, if you know what that means. If you don’t, don’t worry, Glyphs takes care of this automatically.

Note 2: For a case like MyFontFamily Compressed, where the style name is purely expressible with WWS, name IDs 21/22 are not required, remember? But actually, the spec does not preclude including IDs 21 and 22, provided this fsSelection bit 8 is set. So if you feel like it and have a lot of time to kill, you can add them everywhere. But really, finish early and have an ice cream instead. If you want to take control of fsSelection bit 8 yourself, add the Has WWS Names parameter to your instance: According to the OpenType specification, this bit indicates that ‘the font has “name” table strings consistent with a weight/width/slope family without requiring use of “name” IDs 21 and 22.’ Keep in mind that this makes sense only if the naming of your font already adheres to the WWS scheme.

Naming for Adobe Menus

Fonts in Adobe menus are sorted into submenus based on their Family Name. This can be overridden by the Preferred Names (Name IDs 16 and 17). So if you don’t like the submenu arrangement, you can make your own submenus with PreferredFamilyName and put the rest of the respective font name into PreferredSubfamilyName.

Inside the submenu, the fonts are sorted by, and in this order:

1. by the width class,
2. by the weight class,
3. by the slope (upright or italic),
4. alphabetically by the style name.

You can set the width class by choosing from the Width menu (1), a weight class from the Weight menu (2), the slope with the Italic button (3), and the alphabetic order, of course, with the Style Name (4). Furthermore, if you need to differentiate further when it comes to width and weight classes (because several of the options will yield the same number displayed to the right to the menu), you can add widthClass and weightClass parameters and directly set the number for ordering.

Hint: Older versions of MS Office would automatically bolden fonts with weight classes lower than 250. This can lead to the weird effect that the Extralight with weight class 200 appears bolder than the Light with weight class 300. To avoid that, make sure your lowest weight class is 250 or higher. Of course, if you only cater to users with newer versions of MS Office, or no MS Office at all, you can ignore this and start at 100.

That means that you can do anything you like! If you want all the fonts to be in the same submenu, you just make sure that the preferredFamilyName is the same for all fonts. If, however, you want to have your fonts in different submenus, you can differentiate with the same parameter.

Just keep in mind that you only need to set these parameters if they differ from the Family Name and Style Name entries. Otherwise they are not necessary. In other words, only use the Preferred Names to override the defaults established by Family and Style Name. Needless to say, it makes no sense to override them with the same values.

Example: Let’s say you have a Weight and a Width axis. And let’s further assume that you have 5 widths and 9 weights, i.e., 45 fonts in total. Imagine that submenu, whoa. You have two choices:

(A) You want to keep all 45 fonts in one menu. Then you don’t have to change anything in the above setup. Congratulations, you can go and have a drink now.

(B) You want to have the font in five different submenus for the five widths. That way, you clutter your font menu with five entries instead of one entry, but at least your submenus will only have 9 entries each instead. In that case you would use the preferredFamilyName for all non-normal widths, e.g., ‘MyFont Compressed’, ‘MyFont Condensed’, ‘MyFont Semiextended’, and ‘MyFont Extended’. For the normal width, the ‘normal’ Family Name ‘MyFont’ suffices. Thus, it does not need a Preferred Family Name.

Windows vs. Mac: Full Name vs. Compatible Full Name

Windows uses Name ID 4 (‘Full Name’) for displaying the full name of the font, e.g., in a menu. Usually it consists of the family name, followed by a space, followed by the style name. This is also how Glyphs autocalculates the ID 4 name. You can override it with a Name Table Entry parameter (see below). So far, so good.

The Mac also uses Name ID 4 for this purpose. That is, unless there is Name ID 18 (‘Compatible Full Name’) present in the font. In other words: If, for whatever reason, you cannot live with the ID 4 name in your Mac menus, you can have a different name by adding a custom parameter called compatibleFullName to your instance in File > Font Info > Instances.

Needless to say, only do this if you have a really good reason. Using compatibleFullName may break cross-platform interoperability of documents. You have been warned.

Compatible Name Table

I told you above that Glyphs automatically takes care of juggling the Name table entries into their right spots, so that stuff works best in Adobe apps, as well as in Microsoft Office and CoreText apps on the Mac. Most apps are covered this way.

Occasionally, however, you will have a customer that complains. Especially users of Quark XPress and legacy versions of FontExplorer. If you hear the complaint that the font family is not correctly grouped in those apps, you can use a custom parameter called Compatible Name Table. It will cause Glyphs to export a legacy-style name table.

The font family will then be grouped properly in Quark XPress and FontExplorer. However, it will mess up family grouping in other apps, including Microsoft Office. Can’t have it all, I am afraid.

The PostScript Names

The PostScript names are a legacy from the PostScript Type 1 era. Some apps, and some (especially PostScript-based) file formats will use the PostScript Font Name for storing font information in documents. The PostScript Full Name is intended for the human reader only. Again, both are set automatically by Glyphs, and you will most likely not have any problems if you simply let the app do its magic. So you can jump to the next headline in this tutorial unless you have a really good reason to set it yourself.

The PostScript Font Name can be set in File > Font Info > Instances with a custom parameter called postscriptFontName. It is tricky for two reasons: the length of the name, and the character restrictions. Technically, the maximum length is 127 characters, which should be good enough for almost all fonts. Some legacy software like the Adobe Type Manager (ATM), however, only considers the first half, i.e., 63 characters. In other words, old apps may not be able to differentiate between two fonts, or even malfunction, if the first 63 characters of their PostScript Font Names are the same. The good news: If you do not care about legacy software, you can ignore this restriction. But if you do care about legacy compatibility, it can get even worse: early PostScript interpreters cannot have more than 29 (yes, twenty-nine) characters. Ugh.

Pro tip: The 29-character limit also applies to EOT webfonts. While EOT is rapidly becoming an outdated format, it may still be necessary in some cases, or the client wants to be on the safe side and have all available formats. So, if you are exporting an EOT, you may want to also set the PostScript Font Name, and make sure it does not exceed a length of 29 characters.

In terms of character restrictions, your PostScript Font Name can only contain 7-bit ASCII without control characters, without space, and without these 10 characters: [](){}<>/% because they are reserved in the PostScript language. The hyphen - is reserved for connecting family and style name. In other words, you get to use only these characters:

!"#$&'*+,-.0123456789:;=?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_@abcdefghijklmnopqrstuvwxyz|~

That means that MyFont Condensed Extrabold Italic will turn out to be MyFont-CondensedExtraboldItalic, which is 31 characters long. Let’s further assume that your client demands that you have to support that image setter from 1988, which can handle no more than 29 characters. In order to reach the length limit, you can abbreviate the part that makes up the style name to CdXBdIt. The complete font name, thus, turns into MyFont-CdXBdIt, which counts no more than 14 characters. Now you can dust off those machines from the museum again.

In Tech Note #5088, Adobe recommends these abbreviations for style names:

In case you were wondering, ‘Nord’ and ‘Nord Italic’ were the first released weights of Roger Excoffon’s famous Antique Olive typeface family in 1960. They are wide and very bold cuts. Since a digital version of it was in the Adobe Library, it was added to the list when Adobe put it together. To my knowledge, this is the only occurrence.

And there is the PostScript Full Name which can be set with the custom parameter postscriptFullName, again in File > Font Info > Instances. Here, human-readability is key, since it is the complete name of the font as it is supposed to appear to the user, and is thus allowed to contain spaces. It should be ‘suitable for display in font menus’, according to Adobe.

So we are completely free to write what we want, right? Well, not quite. According to Adobe Tech Note #5088, some systems match the font’s Family Name against the PostScript Full Name ‘for sorting into family groups.’ Therefore, the PostScript Full Name should start with the Family Name. The PostScript Full Name ‘is completed by adding style attributes — generally in this sequence: weight, width, slope, optical size’ (Adobe Technote #5088), e.g., ‘Bold Extended Italic Display’, or ‘Medium Condensed Oblique Caption’, or ‘Semibold Oblique’, or ‘Compressed Poster’, or ‘Light’.

Again, set postscriptFontName and postscriptFullName only if you really feel an uncontrollable inner urge to do so, and would run amok if you cannot do it yourself. Otherwise, just forget about it and let Glyphs set the PostScript names, since these are so easily calculated anyway.

Name Table Entries

If you know what you are doing, and nothing can scare you anymore, you can also do the whole Name Table yourself. You can set each entry of the Name Table for all sorts of languages in all sorts of encodings on all sorts of platforms. All you need to do, is go to File > Font Info > Instances, pick an instance, add the Name Table Entry custom parameter, and then use one of the following structures for its value:

• <nameID>; <nameString>
  Example: 4; MyFont Bold Italic (Windows English Full Name)

In this case, <platformID> will be assumed as 3 (Windows), and successively, <encID> as 1 (Unicode), and <langID> as 0x0049 (Windows English).
Note: Glyphs versions before 2.5 add the space after the semicolon to the entry in the Name Table. This bug has been fixed. If you need to stay compatible with older app versions, we recommend you leave out the space character and start the name immediately after the semicolon.

• <nameID> <platformID>; <nameString>
  Example: 4 1; MyFont Bold Italic (Mac English Full Name)

If <platformID> is specified as 1 (Mac), then both <encID> and <langID> will be assumed as 0 (Mac Roman and Mac English).

• <nameID> <platformID> <encID> <langID>; <nameString>
  Example: 4 3 1 0x040C; MaFonte Gras Oblique (Windows French Full Name)

If <platformID> is specified as 1 (Mac), then <encID> can be a number between 0 and 32, and <langID> between 0 and 150 (see Macintosh platform-specific encoding and language IDs).
If <platformID> is specified as 3 (Windows), <encID> can be between 0 and 10, and <langID> must be a hex number below 0x8000 (see Windows platform-specific encoding and language IDs).

The <nameID> can be anything except 1, 2, 3, 5, and 6, which cannot be set through this parameter. The <platformID> can either be 1 for Macintosh or 3 for Windows. The optional <encID> and <langID> represent either Windows or Macintosh encoding and language IDs, depending on the <platformID>. They must be numbers between 0 and 65536, and can be entered in decimal, octal or hexadecimal form. The AFDKO Syntax specification stipulates that ‘decimal numbers must begin with a non-0 digit, octal numbers with a 0 digit, and hexadecimal numbers with a 0x prefix to numbers and hexadecimal letters a-f or A-F.’

Between you and me, the only two platforms that really matter are platform ID 1 Macintosh and platform ID 3 Windows, or actually, only ID 3 Windows, really. The other platform IDs 0 Unicode, 2 ISO and 4 Custom are hardly, if at all, in use. One of them, 2 ISO, has even become officially deprecated. Still, be careful if you set Name Table entries yourself, especially if you choose the long form of the parameter, because each platform has its own unfathomable list of encoding and language IDs. Haha, they are coming to take me away, hahaha. So, if you really want to do this yourself, you will find yourself surfing to this web page a lot: Microsoft OT Spec: The Naming Table, which lists all the encoding and language IDs your font-geek heart desires.

Here is a quick table of the Name Table entries you can set with <nameID>, except the ones marked with an asterisk. The links take you to the Microsoft spec page:

For most of these entries, there are better ways to set them, usually a text entry field in the UI or a dedicated custom parameter. And if you do, you can usually get away by setting the Windows name only. In other words use the short form of the parameter <nameID>; <nameString> and you’re done.

And again, only do this if for some reason the Name Table produced by Glyphs does not work for you, and if you know what you are doing. Setting them yourself just for the sake of doing it yourself will likely break something.

Many thanks to Rob McKaughan from Microsoft for providing much of the information explained in this tutorial. Some passages are quoting Rob directly.


Update 2017-12-17: Fixed typos, added an example for the preferredFamilyName parameter.
Update 2017-12-17: Added paragraph about Antique Olive Nord. Merci bien, Jean François Porchez! Added some infos about Name Table Entries and PostScript Names in EOTs. Thank you, Phil Garnham!

While each designer might have their own workflow, this tutorial illustrates our recommended step-by-step process to build a Devanagari font by utilizing all of Glyphs’ cool features!

Setting up a Devanagari font file

When you create a new file in Glyphs (File > New, Cmd-N), it will open a window with Latin characters by default. There are two ways to add glyphs for Devanagari – one through Glyph > Add Glyphs (Cmd-Shift-G), or from the sidebar under the Languages > Indic > Devanagari section. Right-click on the subcategories inside Devanagari to see a list of glyphs included in each section then you can select the ones to add to the font:

You can see that all Devanagari glyphs have descriptive glyph names and a -deva suffix. This makes it possible for the app to determine the script of the glyph and automatically build the appropriate OpenType code later on.

The First Step

Let's start with the most basic element of a Devanagari letter, the vertical stroke as found in aaMatra-deva. This defines the most basic proportions of our Devanagari letterforms, and it is used in most glyphs. So it would be great if we could design it once, and use it as a component in all the other glyphs needing it. You will find this character listed in the sidebar under Languages > Indic > Devanagari > Vowels. Or you can manually add it by typing Cmd-Shift-G, then, in the upcoming dialog, aaMatra-deva and pressing the Generate button.

You can also go ahead and add a value for the shoulder-line with the shoulderHeight custom parameter in File > Font Info > Masters (cmd-I). This will help the placement of anchors in not only the aaMatra-deva, but many other glyphs as well.

Pro tip: In File > Font Info > Masters, we can also set an alignment zone for the entire headline thickness (with a negative value that goes down from the shoulder height). this will allow us to easily make sure our shirorekha always has the correct thickness.

A note about spacing: Devanagari usually has a connecting headline, so you will probably want to extend the headline out slightly, so the sidebearings have negative values. You can define a standard value here and it will apply to many glyphs later on as well. Don’t worry, if you change your mind later, it’s very easy to update everything at once.

Setting Anchors

It is never too early to start thinking about anchors. Most vowel and intonation marks will align in the same place relative to the vertical stem, so we can simply add anchors to the aaMatra-deva and they will be automatically copied to any glyph using this as a component. With the shoulderHeight defined, you only need to run Glyph > Set Anchors (Cmd-U), and the anchors will be automatically added at the correct vertical height. You may need to move them horizontally depending on your design.

Hint: In components, anchors ‘shine through’ from their original glyph. So you do not need to set anchors in compound glyphs. However, if necessary, we can override these anchors by placing another anchor of the same name in higher-order components.

Building Compounds from Half-Consonants and Half-Forms

Now we can prepare the components needed for the consonants. Most of the consonants are constructed with a half-form connected to the aaMatra-deva. These half-forms are not only used to form the full consonants, but also to build conjuncts – the ligatures of two or more consonants where the inherent vowel aaMatra-deva has been deleted (e.g. ‘pepper’ = पेप्पर). More about conjuncts later, let’s first design the p-deva, which is the half-form of pa-deva. You may now want to go ahead and add the half-forms from the aptly named Halfform section in the sidebar.

To create the full consonant pa-deva, we can generate that glyph (via Glyph > Add Glyphs…, Cmd-Shift-G), then add the p-deva and aaMatra-deva as components by choosing Glyph > Add Component (Cmd-Shift-C) for both of them. If you are not happy with the alignment, you can just adjust the right sidebearing of the p-deva to look good next to an aaMatra-deva, then the pa-deva should automatically match perfectly.

Using this approach, we can design much of the basic Devanagari consonants. Let’s go ahead and add some more in the same way:

Completing the Basic Consonants

You will notice that not all consonants can be built from half-forms, e.g., glyphs like ka-deva, pha-deva, and ha-deva. These will need custom designed full forms. In cases like this, we generally draw the full forms first, then use those as the basis for their half forms.

There is also a small set of hanging consonants that do not have normal half-forms: tta-deva ttha-deva dda-deva ddha-deva da-deva nga-deva. Instead of turning into a half-form, they receive a ‘halant’ at the bottom (also referred to as ‘virama’). In other words, now may be a good time to draw the halant-deva glyph. Find it in the sidebar under Languages > Indic > Devanagari > Marks. Do not forget to hit Cmd-U to give the halant an anchor.

Once you have the hanging consonants and the halant in your font, you can create the remaining consonants: Choose Glyph > Add Glyphs… and paste this:

tt-deva tth-deva dd-deva ddh-deva d-deva ng-deva

Then press Generate. I.e., the same glyph names, but without the a at the end. Glyphs is smart enough to create them right away as compounds of the respective hanging consonant and the halant.

Spacing Consonants and Kerning Groups

We can start spacing our glyphs by switching to the Text tool (T) in an Edit view. Let’s space the tta-deva next to an aaMatra-deva:

We can go ahead and define the right kerning group for all the consonants using aaMatra-deva at this stage. As for the left groups, you can identify similar left side shapes and define those as well; be sure to also do it for the half-forms.

Hint: To quickly find all compounds containing the aaMatra-deva, right-click on it and choose Show all glyphs using this glyph as component from its context menu.

Conjuncts

Conjuncts are another important element needed to correctly render the Devanagari script. The way you choose to form these will vary depending on your design. Generally, most can be written horizontally/linearly, as a combination of a half-form and full consonant. Others occur either vertically stacked or combined into a more complex letterform – these are referred to as ‘akhand conjuncts’.

In this comparison, you can see how some linear conjuncts are built with default half-forms, and then, their modified, custom versions to make nicer clusters:

If one considers any two, three, four or more consonant combinations, there can be thousands of combinations. Sanskrit requires many conjuncts – and many of them are of the akhand variety. But Hindi, Marathi and other modern languages use conjuncts less frequently. So if one were to support advanced Sanskrit, the number of akhand conjuncts to be designed could easily be a few thousand. Hence, the function of the font will decide the character set. If you are looking to support modern Hindi, Marathi, Sindhi, Nepali, etc., the number of conjuncts required could be considerably less.

Instead of designing all the thousands of possible combinations, Glyphs allows for the linear conjuncts to be automatically composed from the half-forms and full-forms we designed earlier. It will be up to the style and requirements of your design to decide which, or how many, linear conjuncts you will custom-design. In some cases you may need very few, other times you may need lots. There is no easy way around it, you will need to test all the combinations to see which look good by default and which should have custom linear conjuncts.

Generating the OpenType Features

As alluded to earlier, Devanagari requires a lot of complicated OpenType code to get it to render correctly. Fear not, Glyphs can generate it all automatically! Open File > Font Info > Features (Cmd-I). Now just press the Update button and Glyphs will write all the OpenType code needed to preview what you have so far.

If you haven’t noticed already, in the Edit view you can insert any character by pressing Cmd-F. Try inserting a consonant, a halant, and another a consonant. Now look in the lower left corner of the Edit view, and click the Features button: The features and languages your typeface supports are now listed under their scripts. Select Devanagari to see the OpenType code in action:

Different Forms for ra-deva

Now let’s move on to the shapeshifting letter Ra. In Devanagari, the Ra can take on four different forms depending on its context. If it is first in a cluster, it becomes a Reph, and is placed over the vertical stem of the last full-form consonant in the cluster.

If the Ra is placed after consonants with a vertical stroke, it will turn into a ‘leg’, attached to the vertical stem of the preceding consonant:

But wait, there’s more. If the Ra combines with a consonant without a vertical stroke, it becomes a Rakar. This applies primarily to tta_ra-deva ttha_ra-deva dda_ra-deva ddha_ra-deva cha_ra-deva:

But wait, there’s even more! In Marathi, the Ra can also take on the form of an ‘eyelash’:

Phew! Let’s quickly recap these variations.

The Reph and the Rakar are easy. Just create reph-deva and rakar-deva, draw your shapes, and place the anchors with Cmd-U. By the way, both reph-deva and rakar-deva are in the sidebar under Languages > Indic > Devanagari > Marks.

The ‘leg’ form conjuncts takes a bit more effort. Let’s first design rakar-deva.leg (note the dot suffix .leg) to use as a component. This one is not in the sidebar, so just create it manually with Glyph > Add Glyphs… (Cmd-Shift-G). Once we have done that, we can place a _leg anchor in it: right-click in the canvas, choose Add Anchor from the context menu, then type the anchor name:

This leg form of Ra can also appear in the middle of clusters. For that, we should also design ‘half-conjuncts’. Such a concept does not exactly exist in Devanagari, but by utilizing these new glyphs as components, we can dynamically create numerous custom looking conjuncts – without actually having to design every conceivable permutation individually.

To have the rakar-deva.leg automatically connect to the consonants, we should place a leg anchor on all the half-consonants. This way, they will show up as a combination with the half-forms as well as the full-forms. You can then generate the conjuncts from the sidebar, or with Glyph > Add Glyphs… (Cmd-Shift-G) and manually typing names. But pay attention because correct naming of these conjuncts is essential for Glyphs to construct the compounds and automatically generate the OpenType feature code.

It’s important to note that the nomenclature of Ra conjuncts is slightly different from the other conjuncts. Name the conjuncts the way they look. In the case of the text pa-deva halant-deva ra-deva we see a pa-deva with a Ra (the Ra has the form of a leg, but it is a Ra none the less). Therefore we call the conjunct pa_ra-deva. Once you make the conjunct glyphs using the anchor, you might want to change the position and angle of the leg depending on the consonant it appears with. In some cases, you may have to decompose the components to ensure that the leg does not clash with the consonant.

Pro Tip: you can make your rakar-deva.leg as a smart component to allow for modifications without decomposition.

Let’s make the ‘half-conjunct’ for pa-deva halant-deva ra-deva halant-deva. Following the visual-appearance model of naming, our new glyph should be named p_ra-deva:

Creating half-conjuncts will speed up the generating of the full-form akhand conjuncts. And it will allow for more dynamic building of complex linear conjuncts, like this fake one:

Nukta

This is working great so far but what about the Nukta (nukta-deva)? Begin by drawing this little dot, or using another existing dot as a component. Then hit Cmd-U to add the appropriate anchor.

Luckily for us, anchors found inside components will get used, they ‘shine through’. This usually saves a lot of work (just think about the aaMatra-deva). But sometimes the anchor position in a component will cause problems with more complicated conjuncts. Then you can override the anchor by placing an anchor with the same name in the compound.

Now let’s look at this p_ra-deva that we just made. In cases like these, we can avoid this overlap by adding a nukta anchor in the p_ra-deva glyph. Now anytime you use this component, the new anchor will always override the nukta that shines through from the p-deva:

Creating Vowel Marks

Devanagari vowel marks, or ‘matras’, are forms of vowels that appear in combination with consonants and conjuncts. Most will be positioned automatically with the help of top and bottom anchors. We took care of this already when we created the stem anchor at the beginning:

Just like with the nukta anchor, you should check each glyph and the vowel positions, because on certain combinations, they will need to be adjusted.

iMatra-deva

The i matras are another exception to the rule. They need their own special imatra anchor to work properly. (Hint: iiMatra-deva gets an iimatra anchor.) Depending on your design, you might choose to create any number of iMatra-deva length variations. The iMatra-deva glyph should extend to connect with the vertical stem of the modified letter, and this can vary significantly because of the numerous conjunct possibilities. But this is also a stylistic decision, so you may want more or fewer options.

Create as many iMatra-deva variants with number suffixes as you feel necessary: iMatra-deva.001 iMatra-deva.002 iMatra-deva.003, etc., and give each of them an imatra anchor (Cmd-U). Glyphs will use these anchors to calculate which iMatra-deva variant is best fitting to your top anchors in your main consonants and conjuncts when it is generating the OpenType code. To check on the result, see the pres feature in File > Font Info > Features.

Hint: In the mekkablue scripts repository, there is a script called Masters > Variation Interpolator. It will create any number of interpolation steps between the foreground and background of a selected glyph. So you can draw the shortest i matra in the foreground layer, select all (Cmd-A) and copy it to the background layer (Paths > Selection to Background, Cmd-J), switch to the background (Paths > Edit Background, Cmd-B), and turn the i matra into its longest variant, while keeping the outlines compatible with the foreground. You can Ctrl-Opt-drag the nodes at the tip to extend curves elegantly. Once you are done, run the Variation Interpolator script, and update your features.

There are more nice tricks to setting up the iMatra-deva length variations. They can be also be made with smart components. This will soon be covered in a separate post.

So, that is an overview of our recommendations for developing Devanagari fonts. Gone are the days of being overwhelmed by complicated OT coding, you can now just focus on making beautiful typefaces and let Glyphs do the heavy lifting in production.

Guest tutorial by Kimya Ghandi and Rob Keller (Mota Italic, Mumbai).
SAMPLE FONT: VESPER DEVANAGARI BY MOTA ITALIC

Welcome to Variable Fonts in Glyphs! This tutorial covers a workflow for app version 2.5. Keep in mind that, while Glyphs can export working Variable Fonts, the implementation is currently in beta. Throughout this tutorial, I will point out where you still have to be careful.

What are Variable Fonts?

If you have not read John Hudson’s excellent introductory article, stop right now what you are doing, and read it. No, really.

Step 1: Define Axes

In File > Font Info > Font, add a custom parameter called Axes. Double click its Value field. In the upcoming dialog, click on the gear buttons to add and remove axes. Pick one of the predefined axes (Weight, Width, Italic, Slant, Optical Size), or make up your own.

Pro tip: If you make up your own ‘private’ axis, you will also have to pick a four-letter tag. To avoid potential collision with updates of the standard, it is recommended to keep your private tag in all caps, e.g., SMIL for Smile or ROTN for Rotation. That is because all-caps tags are officially reserved for private use. Predefined axes will always be lowercase.

You can redefine your axes any time, and in the current implementation, you can define up to 6 axes. In this example, I will stick to one axis, Weight, with the tag wght:

You can manage your axes with the gear menu in the lower left corner of the dialog sheet.

Step 2: Set up Masters

In File > Font Info > Masters, add masters with the plus button in the lower left corner of the window, very much like you would for a Multiple Masters project. In our example, we will add two masters, Light and Bold.

For each master, pick the following settings:

1. Make sure you pick an appropriate master name for each master. In our case, I would say Light and Bold are good guesses. The master names are not exported into the final font file. They are important for your own orientation when you work in Glyphs.
2. Most importantly, set the axis coordinates for each master. In our example, set the Weight value, e.g., 50 for the Light Master, and 200 for the Bold Master. Many designers like to use the stem thickness as value for the weight axis value, but you can enter whatever you like, as long as the values are sufficiently different, so that Glyphs can calculate intermediate instances. In our example, we could calculate an instance at numbers between 50 and 200, e.g., 75, 120, 182, etc.
3. Optionally, pick a master icon from the pop-up in the top right of the window. You can select from a range of lowercase n’s representing all sorts of weight and width combinations. You can also enter a glyph name at the bottom, and Glyphs will use an image of the respective glyph as master icon. Again, this is only for your orientation, so pick something that makes sense to you.

Of course, if you scroll down a little in the window, you will find many more settings: zones, stems, custom parameters. You should set them to whatever is appropriate for your design. Just make sure the entered values are compatible. That means that if you add a value in one master, you have to add a corresponding value in all other masters. E.g., if you have some standard stems in one master, the other masters must have the same count and order of stem values as well.

Beta note about axis coordinates: Technically, each axis has a definition of a scale with specific semantics. E.g. the Weight scale must be compatible with usWeightClass to work with CSS and and aloow switching between fonts while keeping the same relative style. Thus, 400 must be the Regular, and 700 must be the Bold, etc. The Width class must have 100 as the coordinate for the normal width, and the numbers for other masters must be the relative percentage of width vs the normal width, usually 75 for a Condensed, or 125 for an Extended.

Achieving this is a little tricky for the Weight axis in the current implementation. You may either use the spec-defined ranges instead of the stem width, or add Axis Location parameters (see below) to remap the masters. Both options have the downside that the predefined weights between your masters are unlikely to distribute as evenly as usWeightClass assumes. In other words, if you have a Regular master at 400 and an Extrabold master at 800, you are more likely to win the lottery than to have the luck that your Medium instance happens to fit perfectly on 500, the Semibold instance on 600, and the Bold instance at 700.

You could theoretically circumvent this by inserting your instances as masters. This is possible by going to File > Font Info > Instances, selecting one instance after another, and choosing Instance as Master from the Plus button in the bottom left corner of the window, and subsequently switching to the Masters tab of the same window, and resetting their Weight coordinates to usWeightClass numbers. Back in the Instances tab, you can then delete and reinsert the instances with the Add Instance for each Master option, again from that little Plus button.

For now, we recommend to do this only for a seriously shipping font, and not care too much about it while you are experimenting for yourself or for a specific implementation.

Step 3: Draw Compatible Glyphs

To keep it short and simple, we will stick to an uppercase A for this tutorial. I draw the light A with a stemwidth of approximately 50 units, and the bold A with a stem 200 units wide:

Most importantly, keep all your outlines, components and anchors compatible, just as you would in a Multiple Master setup.

Pro tip: You can check compatibility with View > Show Master Compatibility (Ctrl-Opt-Cmd-N), but as long as you do not have any instances defined (see step 4), Glyphs will tolerate outline incompatibility. In File > Font Info > Font, you can add a custom parameter called Enforce Compatibility Check, and Glyphs will connect masters even if there are no instances between them:

Step 4: Add Predefined Instances

Even though our font is variable, and we have an endless amount of instances already, we can still pick some spots in the design space and define them as instances for the font submenu. In File > Font Info > Instances, add as many of those predefined instances as you like. Simply add new instances with the plus button in the lower left, or Option-drag an existing instance entry in the left sidebar to duplicate it.

All you need to do in each instance is this:

1. Set an appropriate Style Name: Light, Regular, Medium, Semibold, Bold, Extrabold in our example.
2. Pick a Weight and Width class from the pop-up menu right below the Style Name. What is important is that the numbers next to the menus are in the right order, because this is how Adobe sorts its font menus. In our example, all fonts have the same Width (Medium/normal, 5), but ascending Weight classes (from Light to Extrabold: 300, 400, 500, 600, 700, 800). For in-between instances, you can also add weightClass and widthClass parameters with in-between numbers. Read more about it in the Naming tutorial.
3. Pick a Style Linking. In the uprights, you leave these usually blank, only the Bold is the Bold of the Regular. And every italic is the Italic of its upright counterpart, e.g., Semibold Italic is the Italic of Semibold. Only the Italic instance is the Italic of Regular, and the Bold Italic is the Bold and Italic of Regular. Read more about it in the Naming tutorial.
4. Pick appropriate design space coordinates for each of your axes. Read more about the distribution of weights in the Multiple Masters, part 3 tutorial.
5. And I hate to break it to you, but many Custom Parameters do not work in an OTVar instance, especially all post-processing ones, like filters. If you have any of those in your instance, they will be blissfully ignored by the software. Why? Because they jeopardize outline compatibility.

Step 5: Export and Test Your Variable Font

Choose File > Export and click on the Variation Fonts tab:

If you have the latest Adobe Illustrator or Adobe Photoshop CC 2108, you can export into the Adobe Fonts folder, choose the font in the Character panel, and open the little slider pop-up to experiment with the Weight axis:

Alternatively, you can drop the font file in the Axis Praxis page:

Or, you install the mekkablue scripts and run Test > Variable Font Test HTML, which creates an HTML file next to the latest OTVar export, and opens the enclosing folder in Finder. So all you need to do is drag that into a browser:

The only drawback with the script is that it currently does not acknowledge Variation Font Origin parameters (see below).

Hint: As of this writing, your best guess as browser is the current Chrome or Safari, if you are running macOS High Sierra or iOS 11. It will not work on older versions.

If you do want to use a different browser, take a look at the Axis Praxis blog: There, Laurence Penney explains where to download and how to set up the prerelease versions of all popular browsers. More and more browsers are adding support for Variable Fonts, or already support them, but you need to enable something somewhere. Laurence explains it all in his post.

Add a Virtual Master

Imagine you need an axis which only applies to some glyphs. Let’s say, the crossbar height, which is applicable to letters like A, E, F, H, but not S, D, J, O, etc., and not to any non-letters, like figures, punctuation and symbols. It would not make sense to draw a new master for all the font, would it? Rather, yo would introduce an extra master only for those glyphs that have a crossbar. Well, for cases like these, we have something called a Virtual Master:

1. In File > Font Info > Font, add a new axis to the Axes parameter. I suggest the name Crossbar Height and the tag CRSB:

2. In the same window tab, add a parameter called Virtual Masters, and give it a value of the the Light master for the Weight axis, 50, and a minimum value for the Crossbar Height, let’s say zero:

3. Go through all masters in File > Font Info > Masters, and make sure the axis coordinate for Crossbar Height is not zero but, e.g., 100.

Now that the Virtual Master is set up, you can draw the low-crossbar version of each glyph that needs it:

1. Open the glyph in Edit view.
2. In the Layers palette, duplicate the Light layer with the Copy button.
3. Rename the layer copy to {50, 0}, i.e., curly braces containing comma-separated design space coordinates for Weight and Crossbar Height.

4. Now change the drawing to what the letter should look like with Crossbar Height zero:

That’s it. Now all you need to do is export, and try the font again in Illustrator, Axis Praxis or the Variable Font Test HTML script, et voilà: a second axis is available, for lowering the crossbar towards the baseline:

Optional: Origin

Only one set of outlines is stored in the font. Non-OTVar-capable software will only be able to display these ‘default outlines’. That default is usually your first master. You can pick a different default, though. To do so, go to File > Font Info > Font and add a custom parameter called Variation Font Origin. As its value, pick the name of a master:

Yes, it must be a master. If you want any of your instances to be the origin, you would need to add the instance as an additional master: In File > Font Info > Instances, select the instance you want to define as your origin, open the Plus button in the lower left corner of the window, and pick Add Instance as Master from the pop-up menu that comes up. Now you have an additional master in File > Font Info > Masters, and you can set that as your OTVar Origin.

Two things to consider:

1. Default Appearance: One of the founding ideas behind variable fonts is that you can pick your most used instance as the default, typically the Regular. In Multiple Masters, you designed the extremes of the design space (i.e., your least used instances) and would interpolate everything in between. A variable font can go the opposite direction: it only stores the most important outlines, somewhere in the middle of the design space, and all other instances are derived from that one. So, for desktop fonts, pick the Regular as origin, or whatever the user will expect as the ‘default appearance’ of your font family. If all else fails, this is the weight the user will still be able to use.

2. File Size: Picking a middle master will likely increase the number of your point deltas, and therefore, also increase the eventual file size. On a single-axis setup, it will likely double the number of deltas, if not more. In other words, for webfonts, it makes more sense to pick one of the masters in an extreme end of the design space, because you want to keep file sizes and load times down.

Optional: Axis Location

In File > Font Info > Masters, you can add a parameter called Axis Location. With it you can change the master’s coordinate on the axis. This makes sense if you need different values to be exposed to the users than the interpolation values entered in masters and instances.

In our example, you could argue that a slider going from 50 to 200 may confuse the users of your font. Therefore you want all your sliders to go from 0 to 100, like a percentage. So you will add Axis Location parameters to both masters: Weight 0 for the Light Master, Weight 100 for the Bold Master.

Note: If you add Axis Location parameters, you are effectively changing the axes exported into your variable font. That means you also have to adapt the coordinates of the affected axis in the Virtual Master parameter, if you have one. However, do not change the numbers in Brace and Bracket layers, because those still adhere to the design space created by the original interpolation values.

Limitations

Some things you may have gotten used to, do not work quite as you may expect them to in a variable font.

1. I briefly mentioned above that all post-processing with custom parameters in File > Font Info > Instances is ignored because they are too likely to break outline compatibility or glyph set consistency. That includes filters and the Rename parameters.
2. Corner components work unless they break outline compatibility. But they work differently: in variable fonts, they are applied before interpolation, whereas in a classic Multiple Master setup, they are inserted afterwards.
3. Both Brace and Bracket layers work, but not both within the same glyph. You can have glyphs with Brace layers and other glyphs with Bracket layers in your font, but not a glyph with both Bracket and Brace layers. Sorry about that, we’re working on it.

Not really optional: STAT Table

In new fonts, including all Variable Fonts, naming info is stored in the STAT table. STAT is short for Style Attributes, and includes, among other things, information about axes, instances, and something called the display strings, or name strings: These are names for sections on an axis. E.g. a weight axis may be sectioned into Light, Regular, Medium, Semibold, Bold; a width axis into Condensed, Regular, Extended.

The idea behind this is that an application can name a user’s current instance, no matter what his or her slider settings are. Effectively, in a multiple-axis setup, you get n-dimensional fields of possible names. E.g., if your font has a weight and a width axis, you get columns of weights, and rows of widths, like in the table below. And in order to name the combination of a weight in the Bold section with a width in the Condensed section, an application can simply combine the display strings, and ta-daaa, we have ‘Bold Condensed’:

A display string is deemed elidable if it is left out when combined with other display strings. Usually this is the case for default-style names like ‘Regular’, ‘Normal’, or the like. The semibold weight combined with regular width is usually just called ‘Semibold’, not ‘Semibold Regular’; or the normal weight in combination with the italic style is simply called ‘Italic’, not ‘Regular Italic’. Thus, the display name ‘Regular’ is considered elidable.

Usually, Glyphs takes care of this pretty smartly by analysing the names of your predefined instances. If however, you find that the STAT table entries, the display strings, are not properly stored in the file, you can take control with these two parameters in File > Font Info > Instances:

• Style Name as STAT entry: Takes the instance style name as combinable display string for an axis range. As value, use the four-letter axis tag to which the display string applies. Use this only in instances that are non-normal on one axis and normal on all others. That is because the normal attributes have elidable names and do not appear in the style name (e.g., ‘Semibold’ or ‘Condensed’). Example: In the Light instance, use this parameter with the value wght, because Light is a value on the weight axis.

• Elidable STAT Axis Value Name: Declares the instance style name as elidable for the axis specified in the parameter value. As value, use the four-letter tag of the respective axis. Typically, you will add this parameter in the regular style, and you will add one for each axis for which the name is an elidable display string. Example: An instance called Regular has two Elidable… parameters, one with wght and one with wdth as parameter values.

Pro tip: The STAT table is becoming increasingly important. In the not-so-distant future, many applications will require one for the font to load in the first place. Don’t ask me where I have picked it up, but let me tell you that if you want to ship (or keep shipping) fonts for Windows, you want to equip all your fonts with STAT. Hint, hint: This will include the Italic (ital) axis for differentiating between Uprights (value 0) and Italics (value 1).

STAT table sample font: Plantago by Viktor Solt-Bittner and Schriftlabor.
Many thanks to Rob McKaughan for his commentary and advice on this tutorial.

The whole point of an all-cap font is that it should not matter whether the user types the key for the lowercase or the uppercase letter. It should always produce the glyph for the capital letter.

A computer differentiates between letters (and thus, also between upper- and lowercase) by means of Unicode values. For example, uppercase K has the Unicode value U+004B while the corresponding lowercase k is represented by U+006B.

In case you were wondering what the U+ means: it is the marker for a Unicode hexadecimal code. The most important codes, the codes in the so-called ‘Basic Multilingual Plane’ (BMP) have four digits and can be represented with 4 hexadecimal digits, from U+0000 to U+FFFF, in total 65,536 code points, containing the characters for all modern writing systems. Read more in the Unicode tutorial.

A glyph in your font is either accessed by its Unicode value, or, typically the glyphs with a dot suffix, through an OpenType substitution feature, which substitutes a glyph carrying a Unicode value with a glyph that has no Unicode value associated with it. The glyphs with a Unicode value can often be typed (that is, if you have the appropriate keyboard layout), or copied and pasted as text.

Double Unicodes

Luckily, since app version 2.5, you can assign not only one, but several Unicode values to a glyph. You can even have Glyphs assign them automatically in one go:

1. In Font View (Cmd-Opt-1), go to the left sidebar and select Categories > Letter > Lowercase.
2. Select all glyphs (Edit > Select All, Cmd-A).

3. Choose Glyph > Remove Glyph (Cmd-Delete). Confirm the dialog that pops up:

4. In the left sidebar, select Categories > Letter > Uppercase.
5. Again, select all glyphs (Edit > Select All, Cmd-A).

6. Choose Glyph > Update Glyph Info.

Now, all Uppercase letters should have two Unicode value assigned: its original uppercase value, plus the corresponding lowercase code.

Features and Glyph Set

Do not forget to update the automatic and manual OpenType features in File > Font Info > Features (Cmd-I). And consider removing some features that may not make sense anymore when there are no lowercase letters, like the case and cpsp feature.

You may also rethink your glyph set. An all-caps font usually will not need old-style figures, and the lining figures will probably not need any height compensation and can stretch to the full cap height. You may also want to reconsider the design of your parentheses, brackets and curly braces. Your quotes, dashes, bars and slashes will only need to match the caps.

Metrics

If you are converting a font from mixed case to caps-only, and you had a cpsp feature for increasing the tracking between the caps, you may want to incorporate the extra spacing into the sidebearings of the uppercase glyphs containing paths. If you are employing auto-alignment in your compound glyphs, they will follow automatically. To do so, follow these steps:

1. In Font View (Cmd-Opt-1), open the gear menu in the lower left corner and choose Add Smart Filter.
2. In the Smart Filter options, pick an appropriate name, then add the conditions Count of Paths: is greater than 0 and Category: is Letter, and confirm by pressing OK.
3. Make sure the smart filter is selected, and select all glyphs displayed by the filter (Cmd-A).
4. In Filter > Transformations > Metrics, select the Relative option, and add your cpsp increment (typically a value like 5 or 10 units) to the glyphs. Confirm with OK.

Now all your remaining uppercase letters have the sidebearings they need.

Pro tip: You may want to double check if there are some unaligned compounds, as marks may have shifted, and especially RSBs may not be what you want them to be. Again, you can use a smart filter for finding the culprits. This time with the options Count of Components: greater than 0 and Is Auto-Aligned: No.

Vertical Metrics

In File > Font Info > Masters (Cmd-I), you can probably get rid of the Alignment Zones for x-height, ascender and descender. Your Standard Stems only need to match the uppercase stems.

Do keep the Ascender and Descender values around, though, since they will be used to derive the vertical metric values written into the respective OpenType font tables OS/2 and hhea (see the Vertical Metrics tutorial for details). It is best to keep these values around the font master’s highest and lowest bounding box values, typically found in diacritics like Ccedilla and Ohungarumlaut.

The whole point of an all-cap font is that it should not matter whether the user types the key for the lowercase or the uppercase letter. It should always produce the glyph for the capital letter.

A computer differentiates between letters (and thus, also between upper- and lowercase) by means of Unicode values. For example, uppercase K has the Unicode value U+004B while the corresponding lowercase k is represented by U+006B.

In case you were wondering what the U+ means: it is the marker for a Unicode hexadecimal code. The most important codes, the codes in the so-called ‘Basic Multilingual Plane’ (BMP) have four digits and can be represented with 4 hexadecimal digits, from U+0000 to U+FFFF, in total 65,536 code points, containing the characters for all modern writing systems. Read more in the Unicode tutorial.

A glyph in your font is either accessed by its Unicode value, or, typically the glyphs with a dot suffix, through an OpenType substitution feature, which substitutes a glyph carrying a Unicode value with a glyph that has no Unicode value associated with it. The glyphs with a Unicode value can often be typed (that is, if you have the appropriate keyboard layout), or copied and pasted as text.

Double Unicodes

Luckily, since Glyphs Mini 2.0.2 (91), you can assign not only one, but several Unicode values to a glyph. You can even have Glyphs assign them automatically in one go:

1. In Font View (Cmd-Opt-1), go to the left sidebar and select Categories > Letter > Lowercase.
2. Select all glyphs (Edit > Select All, Cmd-A).

3. Click the minus button in the lower left corner in order to remove the glyphs. A confirmation dialog will pop up:

Now, when you export, all uppercase letters that do not have a corresponding lowercase letter, should also get the lowercase Unicode value assigned on export. The change is not reflected in the user interface, but you can test your font with the Adobe Fonts folder or into a separate folder and test your font with TextPreview.

Important: This only works in version 2.0.2 (91) and up. Open Glyphs Mini > About to see which version you have installed. If you have an older version, go to Glyphs Mini > Preferences > Updates, enable both checkboxes and press the Check now button:

Dilemma of the Dotted i

The relationship between uppercase and lowercase is not the same for all languages though. Turk languages, including Turkish, Azeri and Tartar, relate the lowercase (dotless) ı to the uppercase (dotless) I, and the lowercase (dotted) i to the uppercase (dotted) İ, whereas non-Turk languages, including French, English, Spanish and German, relate the lowercase (dotted) i to the uppercase (dotless) I.

The logical problem is now: Which uppercase glyph should receive the Unicode value for the lowercase (dotted) i? If your answer is I, then your font is incompatible with Turk languages. If it is Idotaccent, it is incompatible with all non-Turk languages using the Latin script. A dilemma.

But fear not, there is a viable workaround. In order to support both Turk and non-Turk languages (at least in OpenType- and language-aware applications like Adobe apps), we need to keep these three lowercase glyphs around:

i
idotless
idotaccent

Design i and idotless as an uppercase I without a dot, and idotaccent as an uppercase I with a dot.

Then Glyphs Mini can insert an OpenType feature that swaps i with idotaccent if the language is set to Turkish, Azeri, Crimean Tartar, etc. And the proper relationships between lowercase and uppercase are preserved.

Vertical Metrics

In File > Font Info… (Cmd-I), you can probably get rid of the Alignment Zones for x-height, ascender and descender. Your Standard Stems only need to match the uppercase stems.

Do keep the Ascender and Descender values around, though, since they will be used to derive the vertical metric values written into the respective OpenType font tables OS/2 and hhea (see the Vertical Metrics tutorial for details). It is best to keep these values around the font master’s highest and lowest bounding box values, typically found in diacritics like Ccedilla and Ohungarumlaut.

Problems with Double Encodings

As much as double encodings can cut down on file size, there is also one problem with certain PDF workflows. Copying selected text from a PDF can result in garbled casing of the character stream inside the clipboard, i.e., coPiED tExt caN END uP looKiNg liKE tHiS, unless the PDF was created in a certain way (hint: not with Acrobat Distiller) and the text extraction is also done in a certain way. Don’t worry, this just affects the text in the clipboard, the representation in the PDF will be fine. Then again, text extraction from PDF is flawed anyway, and if this is not much of a concern for you, you’re good.

Update 2018-04-24: Added Problems section. Thanks to Aaron Bell, Khaled Hosny, and John Hudson.
Update 2018-06-29: Added Dilemma of the Dotted i section. Thanks to Mark Richardson (@superfried).

Creating a new Korean font, with such a large character set, can seem like a daunting task—where to begin?! This tutorial will give you all the tools you need to get started with Korean and show you the basics of creating a new Korean font in Glyphs. If you’re already familiar with the Korean language feel free to jump ahead.

The Jamo Alphabet

The Korean script is called Hangeul (or Hangul) and is comprised of syllables made up of component letters called Jamo. There are three categories of Jamo: Choseong (consonants at the start of a syllable), Jungseong (vowels in the middle of a syllable), and Jongseong (consonants at the end of a syllable).

Here are all the possible Jamo in modern Korean:

• Choseong (initial): ᄀᄁᄂᄃᄄᄅᄆᄇᄈᄉᄊᄋᄌᄍᄎᄏᄐᄑᄒ
• Jungseong (medial): ㅏㅑㅓㅕㅗㅛㅜㅠㅡㅣㅐㅒㅔㅖㅘㅙㅚㅝㅞㅟㅢ
• Jongseong (final): ㄱㄲㄳㄴㄵㄶㄷㄹㄺㄻㄼㄽㄾㄿㅀㅁㅂㅄㅅㅆㅇㅈㅊㅋㅌㅍㅎ

For more information on these Jamo, how to pronounce them, and other information on Hangeul, please check out the wikipedia article.

Syllable Construction

Hangeul syllables are constructed from Jamo in one of six ways depending on the vowel (Jungseong) used in the syllable:

White is the initial Choseong, yellow is the medial Jungseong, and dark gray is the final Jongseong.

These six different syllables are named based on their structure.

1. Horizontal combination (initial consonant with vertical vowel).
2. Vertical combination (initial consonant with horizontal vowel).
3. Mixed combination (initial consonant with mixed vowel).
4. Horizontal combination with a final consonant.
5. Vertical combination with a final consonant.
6. Mixed combination with a final consonant.

Let’s look at some example syllables:

You’ll note that the relative positions of the Choseong and Jungseong stay the same, regardless of the addition of a Jongseong.

Hint: We recommend that you design at least one of each of these six syllable variants by hand early in your workflow. Doing so will help you determine guides, alignments, and sizes of letters quickly.

Now that you’ve got a basic handle on Korean, let’s get started!

Korean & Unicode

Glyphs makes it simple to add all the Hangeul unicode characters you need for your project. In the sidebar, under the Languages > Korean section, there are different subcategories:

• Jamo Compatibility: This is the unicode block used to represent the Jamo in an isolated form.
• Choseong: These are the consonant Jamo in the initial position.
• Jungseong: These are the vowel Jamo in the medial position.
• Jongseong: These are the consonant Jamo in the final position.

Pro Tip: A key feature in Glyphs is the inclusion of technology that automatically generates the Hangeul syllables. This technology requires the use of the Choseong / Jungseong / Jongseong unicode blocks. If you are planning to build the syllables individually by hand, use of these unicode slots is not necessary.

Hangeul syllables are each represented with their own unicode slots. There are two subcategories that you should consider.

• Basic Syllables: These are the core 2,780 Hangeul syllables based on the KS X 1001 standard and Adobe-KR standards. This is all you need for modern Korean typesetting, and probably what you want to have in your font as well. Trust me.
• All Syllables: These are the full set of syllables (11,172) for anything that could possibly ever occur.

Some other subcategories worth noting:

• Codepages > Adobe-KR: These entries cover the various Adobe-KR standards used for creating Korean fonts. Many major type foundries use these for their fonts.
• Codepages > KS X 1001 (Hanja): This category covers Chinese characters used for Korean text. These characters are not common in modern Korean use.

To add these subcategories to your font, right click on each to list all missing glyphs, press Cmd-A to select them all, and click Generate.

Basic syllable creation

Now let’s get down to drawing! For this example, let’s focus on the glyph 밈 mim-ko, a mixed combination syllable with a final consonant. To create this syllable, we’ll need four glyphs—three Jamo and the full syllable:

mieumCho-ko
iJung-ko
mieumJong-ko
mim-ko

If you don’t already have these glyphs in your font, you can either add them through the left sidebar Languages > Korean, or select Glyph > Add Glyphs… (Cmd-Shift-G) from the top menu and paste the names above in the box. Once you confirm the dialog, and ta-daa, all of the necessary glyphs are added to your font.

Hint: In Glyphs, all Korean glyphs are marked with the suffix -ko. Additionally, to differentiate between which Jamo is at the start, middle, and end of a syllable, the abbreviations Cho for Choseong, Jung for Jungseong, and Jong for Jongseong are used in the glyph name. For example, yiJung-ko denoting the vowel yi, or mieumCho-ko denoting the initial version of the consonant mieum.

Please open the mieumCho-ko glyph:

If you’ve used another program for Korean font development, or have created a Latin font in Glyphs, you may notice that the metric box looks different for Korean characters. Instead of the standard baseline, x-height, cap-height, and ascender values, CJK glyphs are displayed using the em-square with the midway points of the em-square marked as well as the font baseline. This enables you to consider positional alignment with other scripts without being distracted by unnecessary metrics.

Pro tip: Glyphs includes an extremely handy feature called CJK Grid which allows you to add a custom grid. Go to File > Font Info > Masters and in the Custom Parameters field, click on the plus and add CJK Grid as Property. Then set the Value as the number of columns and rows you want. We recommend using 8 for Hangeul development.

Let’s draw the mieumCho-ko glyph something like this:

Note in this example the positioning of the Jamo. Given that this syllable has a final consonant, let's place the first consonant high and to the left as this will ensure that the different Jamo do not overlap one another during automatic placement.

Next, double-click the iJung-ko glyph and draw the basic ㅣshape:

Again, note the placement of this Jamo—off to the right of the previous one.

Finally, double-click the mieumJong-ko glyph. As this is the same Jamo as in mieumCho-ko, feel free to copy and paste the outlines you drew here. Then shift it downward to a position underneath the iJung-ko Jamo you drew:

Now go to mim-ko, and you will see an empty glyph:

Here’s where the magic happens. Glyphs knows that the mim-ko is made up of a mieumCho-ko, iJung-ko, and mieumJong-ko, so it can automatically build the syllable for you. Choose Glyph > Make Component Glyph (Cmd-Opt-Shift-C), and boom:

Pro tip: If you are wondering which Jamo are used for a certain syllable, you can preview the compositions in Window > Glyph Info, and overwrite the defaults with your own compositions by writing your own Glyph Data XML.

If you repeat this process for every Jamo in the Choseong, Jungseong, and Jongseong lists, Glyphs can even build out all 11,000+ Hangeul syllables in the All Syllables set. Wow! You’ve just created your first Hangeul font!

This style of Hangeul font is usually referred to as “out-of-frame style” (a.k.a. “deframe” or “de-squared”) and is a fairly contemporary approach to Hangeul design most often used for display typography.

Jamo variants

In the Basic Syllables section, the same Choseong, Jungseong, and Jongseong Jamo is used for every syllable, regardless of structure. However, what if your design requires that you vary the shape of a Jamo depending on the other Jamo in the same syllable?

In the example below, the ㅁ (mieum, marked in blue) changes shape depending on which final Jamo is used:

Looking at these two sample syllables, you’ll note that the ㄴ (nieun) in the first syllable affords the ㅁ (mieum) more vertical space than the ㄹ (rieul) in the second syllable. As you can imagine, every syllable is different, so suddenly you might find yourself with 5, 10, even 20 versions of each Jamo! It might seem scary, but this variation is absolutely important to achieve proper balance and proportion for text typography.

This style of Hangeul is usually referred to as “in-frame style” (or simply “frame” or “squared”) and is the most common style of Hangeul.

Advanced syllable creation

Let’s try out using Jamo variants. For this example, we’ll focus on the man-ko 만. Please add the following glyphs in your font:

man-ko
mieumCho-ko
aJung-ko
nieunJong-ko

Also create two variants:

mieumCho-ko.man
aJung-ko.man

This time, when we draw the mieumCho-ko and aJung-ko, we will draw them at full height, as if we are designing the character 마 ma-ko. First, here comes mieum-ko:

Do the same with aJung-ko:

For the nieunJong-ko, draw it at the bottom of the box, like so:

Now, when we go to man-ko, and press Glyph > Make Component Glyph, we get a rather unpleasant result:

Oh no! Everything is overlapping! But we have a solution. Remember those two variant glyphs we created? Copy the outline from mieumCho-ko into mieumCho-ko.man (or duplicate the glyph with Glyph > Duplicate Glyph and rename the new glyph accordingly), and raise the bottom of the Jamo so there’s room between the top of the ㄴ (nieun) and the bottom of the ㅁ (mieum).

Pro tip: With Smart Components, you can re-use and adapt shapes much easier. Making Smart Components takes a little time, but it is worth it. Otherwise, you would spend lots of time repeating shapes in all kinds of variations.

Once done, go back to man-ko, and select the mieumCho-ko component and click the name mieumCho-ko in the grey info box below ...

... and the window for selecting components will pop up. Search for mieumCho-ko.man and select it:

This will replace the selected component with its .man variant. Ta-daa! With the .man variant, we’ve solved the overlap problem, and achieved better balance between the Choseong and the Jongseong!

Now, you can probably guess already what remains to be done, and select the aJung-ko component:

If you follow the same steps for the aJung-ko, the final result will look like this:

Nice. You deserve a good shoulder pat now. In this example, we were lucky and didn’t need to make any changes to the nieunJong-ko, but in other syllables it will be necessary to swap in an alternate version for this Jamo as well.

Tip: To edit the original glyph of a component, simply double click the (grey) component, and Glyphs will insert the original glyph in Edit view, and even activate it for immediate editing. This way, you can adapt the .man glyphs, and see the combined result right away in the man-ko syllable.

Congratulations! You made your first “in-frame style” Hangeul syllable! Now, just repeat the process for all 2,780 basic Hangeul syllables, and you’ll be done. Easy, right?

Coming soon: Hangeul composition

Lucky for us, Glyphs includes advanced features for the creation of Hangeul syllables. The Hangeul Composition engine allows you to collect glyph variants in groups, establish rules to determine which Jamo should be used where. Once done, the engine will automatically manage the entire database of syllables for you! But that is for our next Korean tutorial.

Have fun and stay tuned!

Guest tutorial by Minjoo Ham and Aaron Bell.
Thanks to Eunyou Noh, Daekwon Kim and Yanghee Rue for their feedback.


SAMPLE FONTS: GEOJANG AND HAHMLET BY MINJOO HAM.

So you have written that great plug-in, and it works as expected, and your users are happy. But then the first complaints are in: ‘Que? No español?’ or ‘Qu’est-ce que ça veut dire? Pas de Français?’ or even ‘Jahimmelherrgottkruzifix, gibt’s denn koa Boarisch?’

In short, your plug-in only speaks English, but your users are running the app in other languages. If you do not speak their language, usually they will be very cooperative when you ask them how they would translate the interface in question. Or perhaps you meet someone you can ask. What you should not do, is simply run the text through Google Translate, or you may end up with some very confused users. You have been warned.

Step 1: Put your .nib and .xib into Base.lproj

In order for the translation to work, we have to put the files that need translation into a special subfolder. This collection of original untranslated files is referred to as the Base. Hence, the subfolder will be called Base.lproj, because it is the Base of our language project.

Okay, here we go. Go into your plug-in by right-clicking it and choosing Show Package Contents from the context menu. From there, navigate to Contents > Resources. You should find your plugin.py, your IBdialog.nib and IBdialog.xib there. In case you made a more sophisticated UI, there will be more .nib and .xib files.

1. Determine the Base. Select all .nib and .xib files:

2. Collect the Base in a subfolder. Right-click and choose New Folder with Selection from the top of the context menu that pops up:

3. Name the Base subfolder. Rename the newly-created folder to Base.lproj:

   Pay attention: the name is case-sensitive, so uppercase B, and the rest is lowercase.

The Base.lproj folder is the basis, and now we will add language-specific .lproj folders that contain the translations for the Base. But first, we will create the English .lproj. Yes, you read right, English.

Step 2: Add English .lproj folder

Why do we need an English language project folder? After all, the plug-in already is in English. So one would think you would need only the translations anymore. Well, not quite. The point is that the Base is not supposed to change anymore, or as little as possible, because what you will want to avoid at all cost is that the IDs change. (You will read about IDs further on in this tutorial.) That means if you change the English text at a later point, e.g., because you want to correct a typo, you will do that in the .lproj file, not in the .xib/.nib anymore.

1. Create the language folder: Next to the Base.lproj folder you just created, add one folder called en.lproj:

2. Add .strings file for each .nib file: Then fire up your favourite text editor, like Atom, SublimeText or TextMate, create a new file and save it inside the en.lproj folder with the name IBdialog.strings:

   The name must be the same as the .nib file in Base.lproj. Again, the name is case-sensitive, uppercase IB, lowercase dialog, and the .strings suffix.

   If you have other .xib/.nib files besides IBdialog, please add corresponding .strings files, one for each .nib.

That’s it in step 2. If you have done everything right, it will look approximately like this:

So far, so good. But an empty .strings file is of not much use. Let’s add some content. So do not close the file yet.

Step 3: Populate English .strings file

What we need to do now is tell the plug-in that certain text elements get new text content. In order to do that, we have to identify the element with an ID, and assign one of its attributes, typically the title, a new text string.

1. Finding the ID: Open the .xib file in Base.lproj with Xcode and select the text cells that need translation. Attention: Make sure you actually select the text field cell, not just the text field. This is important because field and cell have different IDs. I.e., open the triangle symbols in the Dialog sidebar on the left side. You can also see it by the way the element is highlighted, see the screenshot below.

   Then, with the text cell still selected, choose the Identity Inspector in the right sidebar (the third icon there). Now look for the Document pane in the sidebar, and select and copy the Object ID. Paste the ID in your .strings file. It is a good idea to add a description, or the original English text, in a comment between /* and */, so you know what the ID refers to without opening the .xib file again. So, for now, it will look like this in your .strings file:

   /* "Offset" */
   STH-Ua-fbl

   Do the same for all other text cells in the dialog. If you have placeholders or tool tips associated with the Object ID, consider adding those as well.
    

2. Find the attribute: The Object ID refers to the object, but what we want to do is assign new values to some of its attributes in the context of different language settings. In plain English, we want to translate (=assign new values to) one or more of the text strings (=attributes) attached to the text field cell (=object).

   In order to determine the proper keyword for your attribute, take a look in the Identity Inspector (3rd icon above the right sidebar) or Attributes Inspector (4th icon), and transform the names you see there into camelcase (starting with a lowercase letter), and you have the keywords of your attributes. E.g., Tool Tip becomes toolTip, Title becomes title, Placeholer becomes placeholder.

   You can see there are many other attributes there as well, and you can access them the same way. But usually, for a translation, only the ones that carry text will make sense to include in your .strings file.
    

3. Clean up your .strings code. The content of the .strings file must be in C notation, so our code will have to be transformed like this:

   /* "Offset" */
   "STH-Ua-fbl.title" = "Offset";

   1. Add the attribute as a dot suffix to the ID: STH-Ua-fbl.title
   2. Wrap the suffixed ID in dumb quotes: "STH-Ua-fbl.title"
   3. Append an equals sign: =
   4. Append the assigned text between dumb quotes: "Offset"
   5. At the end of the line, add a semicolon: ;
   6. Double check if your comment is between /* and */

   Do this for all attributes you want to translate. If you have done everything right, your text editor will help you with syntax coloring, and it will look something like this:

Again, an object may have more than one attribute you want to translate. Our example might just as well look like this:

/* "Offset" */
"STH-Ua-fbl.title" = "Offset";
"STH-Ua-fbl.toolTip" = "Width of the shape contour";

That is it for step 3. Keep in mind that, in the future, you should make your changes in this .strings file, not in the .xib anymore.

Step 4: Create non-English .lproj folders

Now that we have the Base and the English language project set up, we need a language project folder for each language we want to support. They are exactly the same as the en.lproj folder we already created, except that, in our .strings file, we will add the translation for the respective language.

Pro tip: Since you will find yourself opening .strings file a lot, consider always opening them with your text editor of choice. Open the file info in Finder (Cmd-I or Cmd-Opt-I), choose your preferred app under Open with:, and click the Change All… button.

Okay, here we go:

1. Create the language-specific language project folders. In Finder, select the en.lproj folder and duplicate it (File > Duplicate, Cmd-D), then rename the new folder to the two-letter ISO 639-1 language code followed by the .lproj suffix:

2. Add the translations. Inside each .lproj, open the .strings files and change the text between dumb quotes on the right side of the equals sign.

Some advice: If you do not speak the language, consider sending the .lproj folder to a user of your plug-in who does and ask them to translate the strings for you. If you do not know anyone, consider a forum post requesting help. For plug-ins, there is usually very little text to translate and it is easy to find someone who will do the favour for free, especially if the plug-in you offer is free as well. If it is commercial, consider offering a free copy of your plug-in in return.

You can add any language of course. First and foremost however, consider the languages that Glyphs.app is localized for already. That way, you can enable a smoother UI experience for users in these languages:

• cs: Czech
• de: German
• en: English
• es: Spanish
• fr: French
• it: Italian
• ja: Japanese
• ko: Korean
• pt: Portuguese
• ru: Russian
• tr: Turkish
• zh_CN: Chinese (simplified, mainland China)
• zh-Hant: Chinese (traditional, Taiwan)

You can see that Chinese appears twice in the list, with two different suffixes. That is because it needs to be differentiated into its two possible script variants: simplified and traditional. The former is written in mainland China, the latter on Taiwan/ROC.
 

Step 5: Re-compile the .xib once

One more thing remains to be done. Since we transformed our plug-in into a localized project differentiating between Base and language-specific customisations, we need to compile the .xib to a .nib again.

You probably know the drill: Open the Base.lproj folder in Terminal.app, type ibtool IBdialog.xib --compile IBdialog.nib and press the Return key. Or, better yet, drag the .xib file on the Compile .xib to .nib.app provided for your convenience in the GlyphsSDK repository.

Pro tip: You can set Compile .xib to .nib.app as the default app for opening .xib files. Then all you need to do is double click the .xib, and you are done.

The good news: You only need to do this once. All future additions and changes to the translations only need to be specified in the .strings files, and you’re good. High five!

Step 6: Localize texts in your Python code

Did we forget something? Yes we did. If you wrote your plug-in in Python, there probably are some strings in your .py file that need to be translated as well: typically the menu name, probably the word on the button, and perhaps als the context menu if your plug-in has one.

In this case, we can keep it inside the .py file. Simply replace all your strings (including Unicode strings) with a Glyphs.localize() function. The localize() function takes a dict as an argument, where the dict keys are the two-letter language codes, and the corresponding values the translations, preferably as Unicode strings.

To give you an example, you would turn this:

self.menuName = 'Shadow'

… into this:

self.menuName = Glyphs.localize({
    'en': u'Shadow',
    'de': u'Schatten',
    'fr': u'Ombreur',
    'nl': u'Schaduw',
    'es': u'Sombrear',
})

Note the u in front of the strings. It will turn the string in a Unicode string. You need this if the translation contains non-ASCII characters. It does not hurt to stay on the safe side, and always add them, though. If you use Unicode strings in your .py file, it may be a good idea to declare the encoding at the beginning of your file, like this:

# encoding: utf-8

By the way, this also works with all your regular Python scripts outside the realm of plug-ins. It even integrates nicely with vanilla code. Pretty cool.

OK, I think that’s it. You now have all the tools for localizing your plug-ins in your hands. Once you get the hang of it, it is some kind of geek fun and you will find it hard to stop. So, feel free to go localize your hearts out. :-)

Test the Localization

In order to test the localization, first make sure you unchecked Glyphs > Preferences > User Settings > Disable Localization. Otherwise you will not be able to switch Glyphs into a different language.

Then go to System Preferences > Language & Region, and drag the languages you want to test on top of the list. If the language does not show up, add it with the plus button. For instance, to test the Spanish localization, add Spanish to the list, and drag it on top, like so:

To confirm your changes, simply close System Preferences again. I dialog will ask you if you want restart your Mac. You do not want to restart your Mac.

You do want to restart Glyphs.app, though.

Pro tip: Quickest way to restart the app is to right-click its Dock icon, hold down the Option key, press the down arrow, which should select Force Quit in the Dock menu, and (do not release the Option key yet!) confirm by pressing the Return key. You just killed Glyphs.app, now you can restart it again. Since your mouse pointer is already over the app icon, simply press the mouse button to make it jump back into existence again. With a little practice, this takes one or two seconds only.

After startup, Glyphs is running in Spanish! Look for your plug-in under the Filtros or Vista menus. Its name should have changed to whatever you españolified self.menuName to. And voilà:

Troubleshooting

Okay, I cannot lie to you, there is always something that will go wrong. If the translation does not show up and you are lost along the way, these few tips will help you spot the problem quickly:

• Not the right object: Did you make sure you are referencing the correct object with the ID you found out? Most typically, you accidentally used the ID that points to the text field, not the text field cell. Make sure that you drill down far enough in the Dialog section of the Xcode sidebar. Look here, the one with the loving smiley is the one you want:
• ID has changed: Did you make changes to the .xib? Perhaps replaced one of the text fields with a new object or pasted one from another .xib in? Chances are the IDs have changed. You will need to both recompile the .xib and especially verify the Object IDs again.
• Forgot the semicolon: In the .strings file, after every assignment, you must put in a semicolon. Cannot spare you that one, I am sorry.
• Recompiled once? Did you recompile the .xib after you added Base.lproj? It does not cost anything to do the compilation once more, so you may want to do that anyway, just to be on the safe side.

Whenever you want to use custom fonts on the web, you need webfonts. And whenever you make webfonts, file size is your main concern. The smaller the better. A well-subsetted single-script webfont should clock in below 20K.

Format Overview

I told you above that file size is the primary issue. Number two on the list will be browser support. Unfortunately, not every web browser can handle every webfont file format. Glyphs can produce four kinds of webfonts: EOT, WOFF, WOFF2, and plain OpenType fonts (TTF/OTF). Here is a quick overview:

• EOT: Embedded OpenType. Internet Explorer only; necessary for versions 6-8 (current combined market share below 0.19%), versions 9 and later support WOFF. More info about EOT support. 
• WOFF: Web Open Font Format. Most widely supported format; Chrome 5, Firefox 3.6, IE9, Edge, Safari 5.1, Opera 11.1, Android WebKit 4.4, and all respective later versions. More info about WOFF support. 
• WOFF2: Web Open Font Format 2. Best compression, but browser support still limited; Chrome 36, Firefox 39, Safari 10 (macOS 10.13 High Sierra and iOS 11 and later only), Edge 14, Android Webkit 67, and Opera 23; not supported on IE, Opera Mini, Android UC, and BlackBerry. More info about WOFF2 support. 
• Plain OpenType: OTF and TTF. Fallback format for old browser versions that do not support WOFF yet: Chrome 4 (0%), Safari 3.2–5.0 (macOS and iOS, approx 0.02%), Opera 10.1–11.0 (0%), Android WebKit 2.2–4.3 (0.28%). More info about TTF support. 

You can pretty much safely ignore both EOT and plain OpenType. Yes, it does not hurt to implement them, but hey. As of this writing, a mere approximate half percent of web browsing may be done in browsers that necessitate these formats. Probably way less by the time you are reading this.

In other words, focus on WOFF and WOFF2. Now, read on.

Exporting Webfonts

Sure enough, to export the fonts you have set up in File > Font Info > Instances, you simply choose File > Export (Cmd-E) and pick the Webfont option in the top row. You are presented with this dialog sheet:

You basically need to make three decisions:

1. OpenType/CFF vs. TrueType: The radio buttons determine in which outline format the WOFF and WOFF2 fonts will be exported; EOTs are always TrueType. TrueType-based fonts use components for keeping the filesize small, PS-based fonts use a technology called subroutinisation. Complex outlines cannot be subroutinised. Windows has performance problems with complex PS outlines, and sometimes you will see a difference in screen rendering, especially with hinting (see following point). Best is to test WOFF and WOFF2 in both formats for file size and screen display quality, and then decide.

2. Autohinting: if activated, ttfAutohint will be used on EOT and TT-based WOFF/WOFF2, and Adobe’s autohinting algorithm will be applied to CFF-based WOFF/WOFF2, respectively. Complex fonts cannot be hinted.

3. WOFF, WOFF2, EOT: The file formats in which the files will be exported, as discussed above. The dialog does not offer the Plain variant. You can use the OTF option in the top row for that, or the custom parameter (see below) for overriding the GUI options. Or simply not care, because it is really not a useful format for the web.

And, well yes, actually the fourth decision, the Export Destination, is the same as in the usual OTF dialog sheet. You can preset a folder, which spares you the extra save dialog that follows otherwise. That can significantly speed up your export process, especially if you find yourself reexporting a lot in your quest to squeeze another kilobyte out of your WOFFs.

Custom Parameters

You can use the following parameters either in File > Font Info > Instances, or in a .glyphsproject file.

• Webfont Formats: This allows you to specify which formats will be exported of the instance in question. You must use this parameter if you are outsourcing webfont production into a .glyphsproject file. Always Pick WOFF and WOFF2 unless you know what you are doing. And maybe throw in legacy EOT and Plain TTF files.
• Webfont Only: Will fiddle with the tables inside the font in a way so that a rogue user will have difficulties reverse-engineering the OTF or TTF from the webfont. However, we do not recommend this. Use this parameter only if your client insists on this as an additional safety precaution.
• Save as TrueType: Forces the TrueType option of the export dialog.
• Autohint: Forces the Autohinting option of the export dialog.

But wait, there are more custom parameters available for your webfont geekery. Read on.

Subsetting

Subsetting refers to the removal of (unnecessary) glyphs from the font, thereby making the font a little smaller in terms of filesize. There are basically two mutually exclusive ways to achieve subsetting in Glyphs: either specifying which glyphs you want to keep, or which glyphs you want to get rid of. In both cases you take care of the subsetting with a custom parameter in File > Font Info > Font, or in a .glyphsproject file:

• Remove Glyphs: You supply a list of glyph names to specify which glyphs will not make it into the exported webfont. Simply type out all glyph names, separated by newlines.
• Keep Glyphs: same as above, except this time you specify which glyphs you want to export. All other glyphs in the font not mentioned in this parameter will not be exported.

In both cases, you can speed up things by using the Copy Glyph Names > One per Line command from the context menu in the Font tab (Cmd-Opt-1). And then paste your clipboard content into the parameter value. The only glyphs you cannot remove are .notdef and space.

And you can use the asterisk (*) as a wildcard, both at the beginning and end of a word. E.g., you may want to write ord* instead of spelling out ordfeminine and ordmasculine, or *.ss05 for all stylistic set 5 glyphs, or even *.ss* for all stylistic sets.

Even better, there are also key wildcards available. They allow you to add complete categories, subcategories and even scripts to the list of glyphs to be removed (or kept). A key wildcard consists of the case-sensitive glyph info key (script, unicode, category and subCategory), followed by an equals sign, which in turn is followed by an appropriate value for the key. Say you want to get rid of all Greek letters, all lowercase letters and all figures, so you add these lines to your Remove Glyphs parameter:

script=cyrillic
subCategory=Lowercase
category=Number

And you can combine the key wildcard with the asterisk. E.g., in order to delete all glyphs with Unicode values from U+0300 to U+04FF, you would add this to the parameter value:

unicode=03*
unicode=04*

OK, now that we have the tools for subsetting in our hands, what do we get rid of? Here are a few inspirations:

• Small caps: *.sc
• Figure variants: *.tf *.tosf *.osf *.lf
• Stylistic sets: *.ss*
• Character variants: *.cv*
• Ornaments: *.ornm
• Very rare, deprecated, unused or untypable letters: AEacute aeacute Aringacute aringacute IJ ij napostrophe Oslashacute oslashacute
• Localizations and compatibility glyphs: Tcedilla tcedilla Ldot ldot
• Rare symbols: lozenge paragraph currency florin logicalnot infinity integral product summation radical micro partialdiff perthousand registered trademark bar brokenbar dagger daggerdbl estimated apple
• Letters for languages that are not necessary on the website it is intended for. E.g., on that page dedicated to Dutch literature, you will very likely not need those extra glyphs that are only used in Esperanto, Ccircumflex ccircumflex Hcircumflex hcircumflex Jcircumflex jcircumflex.
• Letter of scripts that are not needed for the purpose of the font. Bulgarian webpage? You will need Cyrillic, maybe a little Latin, but probably not the Greek parts of the font, so you go: script=greek.

Anything else? Sure, but your mileage may vary. So, after export, always verify the glyph set and see if there is one more glyph you can take out. To do that, it is a good idea to export and test often. You can quickly open your font in apps like OTMaster or FontTableViewer, or on test pages like Wakamai Fondue or FontDrop, see further below for more info on those. Did an unnecessary glyph still make it through the limbus? It will not go unnoticed.

Pro tip: If you find yourself exporting very often, export as regular OTF without overlap removal and without hinting. It is much quicker. Once you have the perfect subset, you can go back to full-blown, proper production-ready WOFF exports.

Feature Subsetting

If you have done subsetting, and you export, you may end up with an error dialog like this:

The dialog reports a MakeOTF Error in the feature code. Usually a ‘syntax error’, and then it mentions a glyph name (brevecomb in this example), and the exact spot: which line in the features.fea file inside the font’s Temp folder (line 74 in this example), and which line inside which feature (line 2 in ccmp in this case). What most likely caused the error is a glyph name that still appears in your feature code but points to a glyph that is removed by the subsetting. In other words, the feature code in File > Font Info > Features is not in sync with the glyph structure in the subsetted instance.

If the feature in question is an automatic feature, this should not have happened in the first place. But it can happen if you have some complex custom parameter stuff going on. In that case, you may need to force the automatic update, simply by adding this custom parameter to your instance, and activating its checkbox, of course:

• Update Features: force-refreshes all automatic OpenType feature code (including classes and prefixes) if enabled.

If, however, you have non-automated manual feature code, you may want to consider one of these parameters:

• Remove Prefixes: takes a list of prefix names and deletes them during export.
• Remove Classes: takes a list of OT class names (without the preceding at sign), and deletes those at export.
• Remove Features: takes a list of four-letter OT feature tags, and deletes the respective features at export.
• Replace Prefixes: supply the name of a prefix as it appears in the sidebar, followed by a semicolon, followed by new code, which is inserted at export time instead of the original code.
• Replace Classes: supply the name of an OT class (without the preceding at sign), followed by a semicolon, followed by new code, which is inserted at export time instead of the original code.
• Replace Features: supply the four-letter feature tag of a Feature, followed by a semicolon, followed by new code, which is inserted at export time instead of the original code.

More Filesize Reduction

Experience shows that the most significant reductions are achieved by subsetting, but there are more ways to squeeze another kilobyte or two out of your WOFFs. To find out what causes the most weight gain in your woff, see how big the tables are in your WOFF. The best way to do this is to download and install fonttools, and list all font table by running ttx -l fontname.woff in Terminal. Or better, you type ttx -l followed by a space, and then drag the WOFF into the Terminal window, which inserts its file path, then press Return. If everything went fine, you will get a list of tables similar to this:

    tag     checksum    length    offset
    ----  ----------  --------  --------
    CFF   0x9C30A665     29398      2992
    GDEF  0x3C093D1F       189     32392
    GPOS  0x15445ACD     13356     32584
    GSUB  0x42EA82BB      1429     45940
    OS/2  0x68B4820A        78      1372
    cmap  0x8F4E4BFE      1042      1928
    head  0x12AB135E        52       292
    hhea  0x066A05BF        32      1340
    hmtx  0x1BC61668       994       344
    maxp  0x02435000         6       284
    name  0x76A3CF96       475      1452
    post  0xFFB80032        19      2972

Look at the length column: You can tell that the table with the tag CFF (Compact Font Format, with PS outlines) takes up the most space, closely followed by GPOS (glyph positioning). CFF, cmap and hmtx are directly influenced by the number of glyphs in the font, while GDEF, GPOS and GSUB get their gravy from all OT features (including kerning) in your font. CFF is also where the PostScript hinting info is stored.

Let’s take a look at a typical TT-based webfont:

    tag     checksum    length    offset
    ----  ----------  --------  --------
    DSIG  0x00000001         8     14124
    GDEF  0x01C701B8        28       384
    GSUB  0x4C1A4D0D       492       412
    OS/2  0x697CB056        76       904
    cmap  0xEFD48A4D       628       980
    cvt   0x0CE0037F        40     12208
    fpgm  0x9E3611CA      1729     12248
    gasp  0x00000010         8     12200
    glyf  0xE8E7B58E      8718      1608
    head  0x112593E0        53     10328
    hhea  0x088C054F        32     10384
    hmtx  0xDBC80FBB       336     10416
    loca  0x668F76DC       216     10752
    maxp  0x033E0F25        32     10968
    name  0x6F5D0BBB       348     11000
    post  0x55CEA4FD       852     11348
    prep  0x6846C89C       143     13980

In TrueType fonts, outline info is stored in the glyf table, typically the largest table in the font. TT hinting info is spread across prep, gasp, cvt, and fpgm.

So, depending on where you count the most bytes, you can make an informed decision on which file reduction steps you want to take next. Here are a few suggestions.

Reduce hinting:

Are you exporting TT-based webfonts and using the Autohint option? Add a TTFAutohint options parameter to your instance, and fine-tune where possible:

• Limit your hinting: ttfAutohint can be limited to a certain PPM size. Try to keep it as low as possible, only employ it for sizes where it really makes a difference. So, keep your Hinting Limit low, e.g. below 50, and employ a small Hint set range that encompasses only the most important PPM sizes, e.g. 12 to 32.
• Avoid extras such as Hint composites, Adjust subglyphs, Detailed info, and ttfa table. They are usually not needed, and can take up quite a bit of space.
• Activate No Autohint Info. It is not much, but hey.

If you are exporting CFF-based webfonts, perhaps only apply hinting to the glyphs you need most. Consider a custom parameter called Disable autohinting for glyphs and supply a list of glyph names that should be excluded from hinting.

If your font is for catering only or mainly to Apple hardware: Consider removing hinting altogether, or perhaps also supply an unhinted version that is delivered only to Apple devices. If your web admin knows how to do that, of course.

Reduce kerning:

A lot of kerning will evaporate once the involved glyphs have been removed. But the kerning that is left may still be a burden on the file size.

Get rid of smallest kern pairs. Anything up to a certain threshold value can go. Depending on the design, that can be 5 or 10 units, for instance. In the mekkablue scripts you will find a Metrics > Delete Small Kerning Pairs that will help you with this task.

Needless to say, do this only with a copy of your font.

Mark attachment:

Consider a Remove Glyphs parameter for deleting combining accents—of course only if your font uses scripts that do not depend on them, e.g., Latin, Greek or Cyrillic. The lack of combining accents will prevent Glyphs from building the mark (Mark Attachment) and mkmk (Mark-to-Mark Attachment) features and therefore reduce the size of your GPOS table. You can achieve that by removing all *comb glyphs.

Be careful though, it may backfire: TT-based files may become larger because they cannot employ the combining accents as components in your diacritics anymore. So, always test, compare and verify. If the file size grows, instead of deleting the combining accents, consider a Remove Features parameter with:

mark
mkmk

CFF-based fonts should always slim down when you get rid of combining marks, because they do not use components in the first place.

More compression:

For CFF-based WOFF and WOFF2 fonts, you can also try disabling subroutinisation. The compression used by WOFF and WOFF2 sometimes actually does work better. It is worth a try, so add the parameter Disable Subroutines to your instance, flick on its checkbox, then export and measure file size.

Testing

According to Miguel Sousa from Adobe, a font that is not tested is a broken font, and he is right. But how do you test a webfont? In browsers of course: Safari, Chrome and Firefox on the Mac, and in Chrome, Edge, and Firefox on Windows. And how do we do that, ‘test in browsers’? Well you have several options.

First of all, right after export, you can run Test > Webfont Test HTML from the mekkablue scripts. It will create an HTML file for the current file (.glyphs or .glyphsproject) inside the last folder into which you exported a webfont. And it will open that folder for you straight away. Open the HTML in a browser of your choice, activate OT features, type your test text, and see your font in several sizes. It also provides sample CSS code.

Or you can drag your finished WOFFs into Viktor and Clemens Nübel’s fantastic FontDrop, which they developed for Monotype. Drag your WOFF in, get an overview of your complete font. Good for testing font info, hinting (with waterfalls) and glyph set. Heck, it even provides spacing indicators!

Similar to this, you may want to use Roel Nieskens’ genius Wakamai Fondue test page. It is insanely great for testing OT features, and even provides sample HTML and CSS code for your copy-pasting pleasure.

The Font Info stores important general information about your font. Open the Font Info tab with File > Font Info (Cmd-I). Then, you can tab through the settings:

Font Names

The most important settings in your Font Info are two names: the Font Family Name and the Style Name. They are the big letters on grey background at the top of the tab.

• Font Family Name: The words on the left, by default ‘new Font’, are your Font Family Name. If multiple fonts share the same family name, they are grouped in the same font submenu, for instance in the font menus of apps like Adobe InDesign. You can use capitalization and word spaces, but do keep the family name short (less than 20 characters in total), and only use ASCII (A-Z, a-z, 0-9). No umlauts, accents or other non-ASCII special characters. For maximum compatibility, it is advisable to avoid a dash in the family name as well. Just saying. Also for maximum compatibility, it is best to start the family name with a letter (A-Z, a-z), even though it is technically possible to start with a figure (0-9). Some apps may complain, list the font wrongly or not at all.

• Style Name: on the right, by default ‘Regular’. If multiple fonts do share the same family name, they have to be differentiated with style names. Very much like brothers and sisters need different first names if they have the same family name. Typical style names are Light, Regular, Book, Medium, Semibold, Bold, Heavy, Black and Light Italic, Italic, Book Italic, Medium Italic, Semibold Italic, Bold Italic, Heavy Italic, Black Italic, you get the idea. But you can have unconventional names as well, like Grunge, Supercool, Dotted, or Laser, whatever describes your design best. Again, keep the style name short, and stick to plain ASCII.

Vertical Metrics

These settings describe some important measurements of your font and influence how your font is displayed in some apps. For instance, apps calculate the first baseline offset based on these numbers.

• Cap Height: The height of your capital letters, best measured at a straight and simps letter without overshoots, e.g., uppercase H, T or I. Most type designs have values between 600 and 700. If your design is much larger, consider changing Units per Em value in the bottom right corner to something that encompasses both cap height and descender. If your font is an icon font, it is best to leave it at the default of 700.
• x-Height: The height of lowercase letters without an ascender, again, best measured in designs that di not have overshoots, like lowercase x, v, w, y or z. If you do not have lowercase letters in your font, make sure it is a value lower than the cap height. Typical x-heights are around 500 units tall, give or take a few.
• Ascender: The height of lowercase letters with an ascender, such as lowercase b, d, f, h, k, l, or the Icelandic þ and ð, not counting overshoots. (Note: the lowercase t usually exceeds the x-height, but does not reach the ascender.) These letters are typically the highest (unaccented) letters in a type design, also exceeding your cap height. If you have a design that reverses that relationship, i.e., caps are higher than ascenders, consider using the Ascender value for your caps, and vice versa. Typically, ascender heights are somewhere between 700 and 800.
• Descender: A negative number value representing the depth of lowercase letters with descenders, such as g, j, p, q, y, and the Icelandic þ, again not counting overshoots. In italic designs, letters like f and the German sharp ß sometimes also have descenders. If your design does not have lowercase letters or maybe not even any letters at all, as in an icon font, it is a good idea to leave this value at its default -200.

The following two settings, the standard stems, are only important for hinting and a few functions like Open Corner form the context menu. If your font does not lend itself for hinting, you can leave these blank. Your font is ready for hinting if:

• your design has extremum points set (Glyph > Add Extremes),
• is a regular text letter design with recurring, similar shapes in its letters (what most people would call a ‘normal font’),
• prioritises legibility over shape fidelity,
• has no special effects like roughened outlines, inlines, flourishes, very fine details, dashed and dotted lines, many nodes (more than a dozen or two), etc.

If, on the other hand, your font is a symbol or dingbat font, or does something fancy with its outlines, like a grunge font, it is better to skip the two stems settings.

• Vertical Stems: The average thickness of your vertical stems. This value will be used to unify and harmonize the number of pixels used to display the thicknesses of vertical stems in low-resolution circumstances. The idea is that if one letter uses, e.g., two pixels for its stems, all the other letters use two pixels as well. So, try to use only one good average value that more or less fits all your letters. Say, you measure the thicknesses of the stems of n, o, H and O, and you get 50, 56, 62 and 68, it is best to enter only one average value of 60. Entering multiple values can lead to a situation where, at certain screen sizes, some letters have stems of one pixel, where others have stems of two pixels, which amounts to a 100% difference.
• Horizontal Stems: The average thickness of your horizontal stems, best measured in the crossbars of letters like lowercase e, f, t, uppercase A, E, H, or T, or the near-horizontal curves of letters like lowercase c, o, s, or uppercase C, G, O, and S. Again, try to find only one good average stem value.

And at the very end of the row, there is a setting that only applies to italic designs:

• Italic Angle: the clockwise inclination of your design, in degrees. Simply put, it is how much to the right your font is leaning. Leave at zero if your font shows no inclination, enter a negative value for backslanted designs. This has two effects: Firstly, it is stored in the final exported font files, and some apps use these values to calculate the slanting of the text entry cursor. Secondly, it slants your measurement box in Edit view, to facilitate editing of italic designs.

Alignment Zones

Like the standard stems above, these settings are intended for hinting and screen optimisation. You can also use them as a design reference for your overshoots. If you decided to not set stems because hinting does not make sense for your font, you can skip the Alignment Zones and move on to the next section.

You can click the Update button, and Glyphs Mini will try and guess your zones. Alignment zones define areas for overshoots and serif cups at your vertical metrics: descender, baseline, x-height, cap height and ascender. The idea is that, at low resolutions, whatever reaches into alignment zones is flattened (‘suppressed’) until a certain pixel size. This is is necessary if an extra pixel would be too much of a difference:

Each zone setting consists of two values: a position and a size. The position should coincide with a vertical metric line (this includes the baseline at position zero). The size is positive for top overshoots at x-height, cap height and ascender, but negative for the bottom overshoots at baseline and descender. An overshoot should encompass anything that is supposed to be flattened onto the same pixel height at a low screen resolution. To give you an idea, here is a typical zone setup:

You need to follow some important rules when setting up your zones, otherwise it will not work as expected:

1. You can have no more than five top and six bottom overshoots (including the baseline).
2. Zones must never intersect or overlap each other.
3. Zones should be kept small, best not exceed a size of 25. (Yes, it is more complicated than that, but you are on the safe side in almost all cases if you keep them below 25 units.)
4. The baseline zone must have position zero.
5. If your grid setting is finer than 1/1 (e.g. 1/10 or 0/1), expand your zones by one unit in both directions, i.e., let each zone start one unit earlier and end one unit later. E.g., the zone 800/16 should be expanded to 799/18. Except the baseline zone, of course, which must remain at position zero, e.g., 0/-14 becomes 0/−15.

Once you have stems and zones set up, you can export (File > Export, Cmd-E) with the Autohint option on. To see if the hinting settings are right, you need to test your font in Adobe apps such as InDesign or Illustrator. To do this, it is strongly recommended to use the Adobe fonts folder.

Meta Infos

This part of the Font Info has no technical implications, they do not change the workings of your font. If your font is just for personal or internal use, you might as well leave these all empty. But if you plan to hand out your font to other people, be it for free or for money, it may be better to include this.

• Designer: This is your name. Or the names of the people involved in creating the font. Let the world know who made this font.
• Designer URL: URL for your website. The spec requires the protocol be mentioned (usually, http:// or https:// for websites).
• Manufacturer: Whoever releases your font. Can be your foundry, your agency, or the company to which your font project is linked to.
• Manufacturer URL: URL of the Manufacturer website. The spec requires the protocol be mentioned (usually, http:// or https:// for websites).
• Version: A version number for your font. Will show up in file info (Cmd-I) in the Mac Finder. Do not forget to increase the number when you are releasing a new version of your font. Referring to a version number can facilitate dealing with support issues significantly. Some validation software out there will consider fonts with version numbers below 1.005 as ‘pre-release’ and warn the user accordingly. So start counting at 1.005. Major changes in the design should be reflected with the single-digit number on the left (a.k.a. major version number). You can use your up and down arrow keys or the buttons to change the triple-digit value (a.k.a. minor version number).
• Copyright: You can use the Update button to let Glyphs Mini autogenerate a valid copyright notice. If you want to release our font as a free, open-source font, it is advisable to remove the part that says ‘All Rights Reserved’.
• License: According to the spec, this is supposed to be a nutshell summary in plain English of what the user can or cannot do with the font, something like Share freely or Only Company X is allowed to use this or Install on max 5 machines. However, many foundries slap in their complete license. Careful if you plan to sell your fonts through reselling platforms. Some of them insist that you do not add any licensing info to your font before you hand it in, because the font may be sold with different licenses for different formats. In other words, they may want you to leave this field blank. So: Ask your reseller before you do anything fancy here. If, however, you want to release your font as a free open-source font, consider the SIL Open Font license.

Style Information

If you only make a single font, you can skip this chapter and move on to Grid Settings further below. But if you are creating a little font family, these infos are important.

Style linking establishes Bold/Italic relationships between multiple fonts. Apps use this info to bring up the right font when you press Cmd-B or Cmd-Shift-B (in InDesign) for accessing the Bold font, and Cmd-I or Cmd-Shift-I (InDesign) for accessing the Italic. In short, every Italic should be established as the Italic of its upright counterpart, while the Bold and Bold Italic fonts should be the Bold or Bold and Italic of the normal/regular style. Use the attributes both Bold and Bold & Italic only once.

Sounds complicated? Fair enough. Let me give you an easy overview, assuming that your default style is called Regular:

• Thin: —
• Thin Italic: Italic of Thin
• Light: —
• Light Italic: Italic of Light
• Regular: —
• Regular Italic: Italic of Regular
• Medium: —
• Medium Italic: Italic of Medium
• Semibold: —
• Semibold Italic: Italic of Semibold
• Bold: Bold of Regular
• Bold Italic: Italic and Bold of Regular
• Heavy: —
• Heavy Italic: Italic of Heavy
• Black: —
• Black Italic: Italic of Black

The dash means, ‘leave the setting empty’. Plus, if your default style is called Book instead of Regular, you will need to reference it with Book, of course.

The weight and width settings change the sorting of the style submenus in Adobe apps. InDesign, Illustrator and Photoshop sort first by Width and then by Weight. If both are the same, then the styles are sorted alphabetically.

The settings are pretty self-explanatory. Simply pick something from the menus that best fits your design, and you are done.

Attention: Please do not ask us how style-menu sorting is done in Apple apps such as TextEdit or Pages. No one knows, and Apple will not tell us. The Mac system does several heuristics on your font family, probably even including measuring some of your glyphs. The only thing we have found out over the years is that for a font to be recognized as upright, it must have an Italic Angle of zero, and for an italic, it must have an Italic Angle other than zero. That is all we know, sorry. If the fonts do not sort the way you expect them to sort in these apps, we cannot help you.

Grid Settings

Towards the bottom of the Font Info, you will find settings for the outline grid. It shows two values, Grid Spacing and Subdivision:

In almost all cases, you want to leave both values 1. In the few remaining cases, the effective grid step, i.e., the places where you actually can put nodes, is determined by Grid Spacing divided by Subdivision.

If you are creating very detailed drawings and you find the grid to coarse, you can increase the Subdivision value. A Subdivision value of 2 gives you half-unit steps through the grid, i.e., it enables .5 coordinates. Maximum value is 100, i.e., two extra decimals for coordinates.

If you need a coarser grid, e.g., for a pixel font or a very modular design, consider a higher Grid Spacing value. A Grid Spacing value of 100 in combination with a Subdivision of 1 will allow nodes only at multiples of 100.

Units per Em

The Units per Em (or in short, ‘UPM’) is the number of font units that make up the font size, default is 1000.

An em is a font-size relative length measurement, where one em is exactly the font size. So, at a font size of 12 points, one em is 12 points. Since we are designing scalable vectors, all our measurements must be independent of specific font sizes, and thus an em is the ideal measurement for type designers.

In other words, by default, each unit is a thousandth of the font size. That means that, if you change the UPM value, you effectively scale the font:

• increase the UPM number if the font appears too big compared to other fonts
• choose a smaller number if the font appears too small

Re-export, best into the Adobe fonts folder or the TextPreview watch folder, and see if the new size fits your needs better.

Warning: Software may expect your UPM to be relatively normal. From experience, make sure your UPM value stays below 4000. This is the threshold beyond which users have been reporting troubles in office software. If you know in which software the font is going to be used, feel free to go higher than that, but do test extensively before giving the files out of your hands.

Update 2019-09-23: Grid Settings and Units per Em rewritten.

So you have prepared vector drawings in Adobe Illustrator, and want to turn them into a font. It is as easy as copy and paste, but there are a handful of details you will want to pay attention to.

Coordinate Precision

In File > Font Info, you’ll find a Grid Spacing value at the bottom of the window. If your Grid Spacing is not zero, all your coordinates will be rounded by your Grid Spacing value. If, however, you set your Grid Spacing to zero, Glyphs Mini will use floating point coordinates, and practically no rounding will occur. (OK, to be precise, you get two decimals, so a little rounding does occur.)

So, if you plan a lot of transformations after import, or if your drawings have very, very fine details, then set your Grid Spacing to 0/1. Otherwise, you usually want to keep it at 1/1. Consider scaling your vector art to the right size before importing it into Glyphs Mini.

Scale: 1 Point = 1 Unit

One point in Illustrator corresponds to one unit in Glyphs Mini. By default, one unit is a thousandth of an em. Or more precisely, whatever you have set your UPM (units per em) value to in the Font Info (Cmd-I). A full em is whatever the user sets the font size to later on.

This means that, by default, your Illustrator drawings are most likely much too small. An average x-height is half an em, i.e. 500 units. And 500 units translate to 500 points in Illustrator. That’s approximately 17.6 centimeters (almost 7 inches), just for the x-height!

It’s a good idea to already scale your drawings in Illustrator. This keeps rounding errors at later stages to a minimum, especially if your Grid Spacing is not zero. For that purpose, you may want to set your measurement units to points, if that is not the case already. You can do that by right-clicking the rulers at the edges of the window or by changing your settings in Illustrator’s application preferences.

Copy and Paste

Now, all you need to do is copy and paste your vector drawings from Illustrator into Glyphs Mini. Make sure you copy only closed paths and make sure you have the right glyph activated when you paste.

There’s one problem though. Illustrator uses one coordinate system for the whole canvas, whereas the coordinates in a font work on a per-glyph basis. Glyphs Mini will recognize coordinates that are way off and ask you if you really want that object placed out of the glyph bounds in 99.9 percent of the cases, you want to Correct Bounds:

Glyphs Mini will then align the pasted drawing either to the baseline or the left sidebearing of the current glyph, or to both, whatever is necessary to bring it back into the glyph bounds. But this may mess up things like overshoots or descenders. Turns out there’s a better way to do that.

Take Control of Positioning

In Illustrator up to version CS4, you can set an origin point by dragging the crosshair from the tiny area in the top-left corner of the window where the vertical and horizontal rulers meet. Glyphs Mini will respect the position of the origin when you paste. Illustrator’s origin corresponds to a glyph’s x=0/y=0 point, i.e. where left sidebearing and baseline intersect.

In Illustrator CS5 and above, you need to set that origin in the artboard options. Bring up your artboard palette, and pick Options from the palette menu, or double-click the artboard symbol, or double-click the artboard tool in the toolbar. You can, for instance, set the height of your artboard to 500pt and its origin to the bottom left corner:

Then you can scale and reposition your letters or symbols like this:

And what about the width of the glyph? After pasting, you can quickly fix the right sidebearing by entering its value in the grey info box. Or, you can set them all at once by selecting your glyphs in the Font tab and then entering the metrics values in the info area in the bottom left of the window.

Cleaning Up

As I mentioned in the beginning, there is much more to say about good paths, but here is a quick and easy way to correct the worst problems:

1. In the Font tab, select all glyphs (Cmd-A).
2. Choose Glyph > Add Extremes. This will insert nodes at extreme positions of path segments. If you don’t know what that means, don’t worry, do it anyway.
3. Choose Glyph > Correct Path Direction (Cmd-Shift-R). This will fix your counters and the path order inside a glyph.
4. Choose Glyph > Tidy Up Paths (Alt-Cmd-Shift-T). This will remove superfluous nodes and doubled coordinates.
5. Unless you need very high detail in your outlines, you may also want to choose Glyph > Round Coordinates which will round all your coordinates to the nearest integer.
6. If you have rather complex vectors with many (100+) nodes or many overlapping paths, consider Glyph > Remove Overlap (Cmd-Shift-O) now. This will speed up export later.

Exporting

When you are done, you can export the font. Unless you have a very regular, ‘normal’ text font, you want to export without the Autohint option.

Always choose Remove Overlap, unless you already did that at an earlier stage. Removing overlaps is a technically complex operation and requires a lot of processing power and therefore slows down export. If you find yourself re-exporting a lot for testing purposes, consider disabling this option.

For testing your font, do not install your font in apps like Font Book or FontExplorer. You will run into font cache problems when you re-export after fixing something. You can better test your font in Adobe apps with the Adobe Fonts folder. Or, test your font as a webfont in a web browser, then all you need to do after re-exporting is reload the test page.

Now, you’re good to go. Have fun.

Update 2020-03-11: changed ‘Font Explorer’ to ‘FontExplorer’ and ’Adobe fonts folder’ to ‘Adobe Fonts folder’.
Update 2020-05-10: fixed typo in the title that had gone unnoticed for years...

Are you experiencing application crashes? Here is what you can do to help us fix the problem as soon as possible.

Sending Crash Reports

After a crash, two crash report dialogs will pop up. The first one is provided by macOS and comes up immediately after the crash. We do not care about this one. Just click Reopen to restart Glyphs:

After Glyphs has restarted, there will be a second dialog bothering you. This time, it is carrying the Glyphs (or Glyphs Mini) logo. It looks like this:

This is the one we care about. Please, always send this one. Always, always, always. The more you send us, the better. Let me repeat that slowly: A…L…W…A…Y…S send the report with the Glyphs icon in the top left and the Send button in the lower right corner of the dialog window. In case you are still undecided, here is a handy diagram that covers all possible circumstances:

And if you fill in the e-mail field, we can get back to you. You only have to fill this in once, and the dialog remembers your info for the next time. Sometimes, we have the suspicion that it is related to a problem in the file. But of course, the crash report does not send any data from your files, and we have no idea what actually triggered the crash. So, if you provide your contact information in the dialog, there is a chance you will receive an e-mail from Glyphs Support asking for a copy of the file you were working on when the crash happened. If you can send us the file, or perhaps just the glyph that is causing the problem, it is much easier for us to figure out what went wrong, and fix the problem.

Can you reliably reproduce the crash? In other words, do you know exactly what you have to do in order to trigger the crash? Please, at least once, describe the steps we can do to recreate the crash. This is very important, because if we know how to trigger a crash, we can fix it very quickly.

Restart the App, Don’t Reopen the File

Want to continue to work on your fonts after a crash? It is advisable to simply start the app again. Do this either with the Reopen button in the crash report dialog, or with a click on the Glyphs icon in the Dock. Glyphs will start up and try to reopen all the files you had open at the time of the crash, in their latest state possible. If they do not open, use the File > Open Recent menu item to reopen your font files.

Do not touch the Autosaved copy next to your .glyphs file. This is the copy that the system keeps around for recreating the last file state. Don't mess with it. (Only exception: use it as a last resort if the original file has been damaged, and in that case, make a copy of it and rename it before you open it.)

Update to the latest Cutting Edge Version

Perhaps the problem that causes the app crashes is already fixed in the most recent betas. Here is how to install the latest possible version: Go to Glyphs (Mini) > Preferences > Updates, make sure the Show cutting edge versions option is checked, and click on the Check Now button.

You will either receive a dialog telling you that you are already up to date, or you will get a notification about a new version being available. In that case, make sure all your files are saved and backed up, click on the Install button, and restart the app when it asks you to:

Is the problem gone? Congratulations, you’re all set. Is it still around? Keep sending those crash reports, please.

Feeling insecure with running a beta? To go back to the latest stable version, you can always redownload the trial app from the Get App page of this website. ‘Trial? But I paid for it!’ I hear you say. Don’t worry. When you open it on your Mac, it will automatically recognize your license and unlock itself.

Disable Plug-ins

Perhaps the problem is related to an extension you have installed? To find out, run Glyphs without plug-ins. The easiest way to do this is to hold down Option and Shift while starting the app.

Note: Glyphs Mini does not support extensions, so this only applies to Glyphs users.

In Glyphs versions prior to 2.5, the Option and Shift trick does not work, so you need to rename your Plugins folder and restart the app. To access your Plugins folder, Go to Script > Open Scripts Folder (Cmd-Shift-Y). The Plugins folder is located right next to your Scripts folder. To deactivate all plug-ins at once, rename your Plugins folder to something like Plugins OFF and restart Glyphs:

If that fixes your problem, one of the plug-ins has a severe bug. To find out which one, create a new Plugins folder, and move the plug-ins back, one by one. Restart the app every time and see if the problem is back. If it is, you have most likely found the culprit.

Please let the developer know about it. If you have the plug-in from GitHub, file a GitHub Issue in the repository of the plug-in. If you have the plug-in from the built-in Window > Plugin Manager, click on the GitHub link to access the GitHub page:

On the GitHub page, switch to the Issues tab, and click on the New Issue button to file a new bug report or feature request:

Hint hint: The developer will be very happy if you can describe steps to reproduce the problem.

Try with Different Document

Try to recreate the crash in a new file, or in a copy of a different file. If the problem occurs in one file only, there may be something fishy in that particular file. Describe the problem in the forum and, if possible, offer to send us the file. We either have a quick answer for you, or will be happy to take a closer look.

Or maybe it occurs in only one glyph? If you can indeed trace the problem back to a particular glyph, then check paths, components, anchors, background layers, layer copies. Try cutting everything (Cmd-X) and pasting it immediately back again (Cmd-V). That forces Glyphs to rewrite the information in the file.

Delete the Prefs

There’s one more thing you can try. The app preferences may be damaged, so we can try deleting them before starting Glyphs. In Finder, choose Go > Go to Folder… (Cmd-Shift-G). For Glyphs Mini, paste this file location in the dialog:

~/Library/Preferences/com.schriftgestaltung.GlyphsMini2.plist

And for Glyphs:

~/Library/Preferences/com.GeorgSeifert.Glyphs2.plist

The dialog will look something like this:

If everything goes well, Finder will take you to the .plist file containing the app preferences:

Move them to the trash by pressing Cmd-Delete, then restart the app. You may have to go through Glyphs (Mini) > Preferences (Cmd-comma) to recreate your preferred app settings.

Delete Autosaves

Perhaps what crashes the app is a file that opens automatically when you open Glyphs. If you know which one it is, perhaps delete the duplicate file that is marked with ‘(Autosave)’.

If you do not know which file it is, quit Glyphs, then go to this folder and delete all .glyphs files you find:

~/Library/Autosave Information/

And then, in this folder,

~/Library/Saved Application State/

… delete everything that starts with com.GeorgSeifert. Then restart the app.

Forum

Still no dice? Please keep sending the crash reports, and make yourself heard in the forum, as described above.

Update 2017-03-04: Fixed typos, clarified the purpose of folder renaming, minor reformulations.
Update 2017-05-14: Added section about deleting prefs.
Update 2018-01-17: Added holding down Option and Shift for starting with plug-ins off.
Update 2018-11-12: Added section about deleting autosaves.

Functions are an efficient way to expand a script, yet keep your oversight and sanity. In this installment, we will use them for some font evil, har har.

This tutorial is part 4 of a series of tutorials and therefore assumes that you have read part 1, part 2 and part 3. This is what we have so far:

#MenuTitle: Glyph Shaker
# -*- coding: utf-8 -*-
__doc__="""
Goes through all selected glyphs and slaps each of their nodes around a bit.
"""

import random
random.seed()

selectedLayers = Glyphs.font.selectedLayers

for thisLayer in selectedLayers:
    for thisPath in thisLayer.paths:
        for thisNode in thisPath.nodes:
            thisNode.x += random.randint( -50, 50 )

So far, so good. I think it is pretty easy to read through it and understand what the code does. It is not that complicated, after all. Still, I want to point you to a few aspects for keeping the oversight in your scripts. First, look at this line:

selectedLayers = Glyphs.font.selectedLayers

This is equivalent to:

currentFont = Glyphs.font
selectedLayers = currentFont.selectedLayers

The first version keeps everything compactly on one line, the second version splits the content into two lines. Performance-wise, there is not really any difference between the two. So either way is fine. However, there are a few arguments for the second solution:

• Firstly, you may want to reuse currentFont several times at a later stage.
• Secondly, debugging is easier. If there is a typo and Glyphs reports an error, it is easier to spot the mistake in short lines. Remember that error messages always report the line number. In our example, the problem could lie either in accessing the current font or in accessing its selected layers. In the first solution, you would not know which, and would have to do some searching on your own. In the second solution, the reported line number directly points you to the problematic part, and you know right away what is going on.
• Thirdly, the second solution keeps your code more legible. This will become very important when you go hunting for a bug.

Yes. Keep your code legible. You will deal with it at a later time. Or worse, you will have to ask someone else to look at your code, and then it is a very, very good idea to keep your code legible. For better code legibility, you will find many tips throughout the internets (Google is your friend), but for our purposes, always remember these things:

• Keep your variable names clear and legible. Use speaking names like currentFont rather than f or currF.
• As explained above, reserve one line per action. Do not squeeze three steps into one line.
• Move distinguishable sets of actions into functions. Avoid creating long sequences of steps, a.k.a. ‘spaghetti code’.

Functions

What? Make my own functions? We talked a little bit about Python’s built-in functions in part 2 of this tutorial, but we have not made our own functions yet. Admittedly, for our script, it was not really necessary yet.

But consider the possibility that we want to expand the script because we want to do more than just slapping the nodes horizontally. For instance, we could also rotate the glyph a little, or randomly move it up and down, or skew it, or randomly add or subtract a few extra paths. Consider our loop:

for thisLayer in selectedLayers:
    slapNodesRandomly(thisLayer)
    rotateLayerRandomly(thisLayer, 5)
    randomVerticalMove(thisLayer, 100)

Looks clean and clear, right? Not really sure what the numbers in the parentheses are about, but otherwise we’re cool: we loop through each thisLayer in selectedLayers, then we slap nodes around randomly, then we rotate the layer randomly by up to 5 degrees, and finally we randomly move the whole glyph layer up or down by up to 100 units. We have not written any code for this yet, but we can already see what we are doing, simply from looking at the function names: slapNodesRandomly(), rotateLayerRandomly() and randomVerticalMove().

So, how do we make a new function? Easy, with the def statement! A function has to be defined before it is called for the first time. So, right before the loop, we insert our function definition:

def slapNodesRandomly(thisLayer):
    for thisPath in thisLayer.paths:
        for thisNode in thisPath.nodes:
            thisNode.x += random.randint( -50, 50 )

The word after def, is the function name, in our case slapNodesRandomly. It must be followed by parentheses () which can contain variable names, so-called arguments, in our case thisLayer. The parentheses are very important, because they differentiate variable names from function names. In other words, when we refer to this function, we would not just call it slapNodesRandomly, but more specifically: slapNodesRandomly(). So everyone knows it is a function we are talking about and nothing else.

In our case, the function contains one argument, thisLayer, which refers to the value that will be passed to it. The variable is local, i.e., it only is valid and accessible inside the function. That means that the word thisLayer has a different meaning inside the function (local function variable) than outside the function (global script variable). To make this distinction more clear, some coders like to apply different variable naming conventions inside functions, e.g., myLayer instead of thisLayer.

Now, all we have to do in our loop through selectedLayers is simply call the function:

for thisLayer in selectedLayers:
    slapNodesRandomly(thisLayer)

This calls the function, and between parentheses, it passes an argument to the function, the global variable thisLayer. And the slapNodesRandomly() function does the same thing we used to have spelled out in the loop. But now, we are ready to expand our script with more functionality, and keep the oversight.

Before we do this, let’s recap. This is our current status quo:

#MenuTitle: Glyph Shaker
# -*- coding: utf-8 -*-
__doc__="""
Goes through all selected glyphs and slaps each of their nodes around a bit.
"""

import random
random.seed()

selectedLayers = Glyphs.font.selectedLayers

def slapNodesRandomly(thisLayer):
    for thisPath in thisLayer.paths:
        for thisNode in thisPath.nodes:
            thisNode.x += random.randint( -50, 50 )

for thisLayer in selectedLayers:
    slapNodesRandomly(thisLayer)

Abstraction

In the world of coding, abstraction means that you take a function and make it more configurable, i.e., fit for more purposes and applications. When we take a look at the current code, slapNodesRandomly() only changes x coordinates of all nodes by up to 50 units. We could make the function more abstract by also offering changing of y coordinates, and allowing other maximum values besides 50. Let’s do just that: First we add extra arguments into the parentheses, and while we’re at it, we also supply default values:

def slapNodesRandomly(thisLayer, maxX=50, maxY=0):

Two things to remember about this: arguments must be comma-separated, and arguments with a default value (a.k.a. ‘keyword arguments’) come after normal arguments. The default values are supplied after an equals sign.

You can still call slapNodesRandomly() the way we are used to. But you can also supply new values and override the defaults. Here are all our options when it comes to calling our function:

• slapNodesRandomly(thisLayer), because you do not need to supply keyword arguments since they can fall back onto their default values: maxX is 50, and maxY is zero.
• slapNodesRandomly(thisLayer, 100) which means that maxX is 100, but maxY still takes its value from the default zero.
• slapNodesRandomly(thisLayer, 90, 80) calls the function with 90 for maxX and 80 for maxY.
• slapNodesRandomly(thisLayer, maxY=70) skips maxX so it gets its default of 50, but sets maxY to 70. Keyword arguments can either be unnamed and in the predefined order (as in the two examples above), or named and in any order, as long as they come after the required normal arguments, in this case after thisLayer.

Of course, we still have to change a few lines to make use of the abstraction. First the line that moves the nodes randomly has to be expanded into two lines, and instead of fixed values, we insert our keyword arguments:

            thisNode.x += random.randint( -maxX, maxX )
            thisNode.y += random.randint( -maxY, maxY )

So, the complete function looks like this:

def slapNodesRandomly(thisLayer, maxX=50, maxY=0):
    for thisPath in thisLayer.paths:
        for thisNode in thisPath.nodes:
            thisNode.x += random.randint( -maxX, maxX )
            thisNode.y += random.randint( -maxY, maxY )

Congratulations, you have successfully abstracted our function. Now we can change the line where we call it:

for thisLayer in selectedLayers:
    slapNodesRandomly(thisLayer, maxX=70, maxY=70)

Now open a font you don't like, select all its glyphs, and let the script do its magic. Har har.

Affine Transformations: Shift

Now that we cleaned up the loop, it should be easy to add new functions. Let’s start with one we mentioned already, randomVerticalMove(). It should randomly move the whole glyph layer up or down. So we know we need two arguments: the layer and the maximum shifting distance. This could be the first line of our function, then:

def randomVerticalMove(thisLayer, maxShift=100):

Next thing, we need to get a random number between negative maxShift and positive maxShift:

    shift = random.randint( -maxShift, maxShift )

And now we need to apply that shift to the whole layer, including nodes, anchors and components. If you look closely on docu.glyphsapp.com, at the methods a GSLayer has, you will find a function called GSLayer.applyTransform() and it takes the six numbers of an affine transformation matrix as an argument. In case your highschool math is just too long ago, this is the meaning of the 6 numbers:

1. Horizontal scale from the origin: 1.0 (means no change)
2. Horizontal shear from the origin: 0.0
3. Vertical shear from the origin: 0.0
4. Vertical scale from the origin: 1.0
5. Horizontal shift: 0.0
6. Vertical shift: 0.0

In other words, a matrix that does nothing looks like [1, 0, 0, 1, 0, 0] and if we want to shift the layer vertically, we need to change the last number. In our case we would just have to insert our variable shift, i.e., [1, 0, 0, 1, 0, shift] is our matrix. That’s it. So the rest of our function looks like this:

    shiftMatrix = [1, 0, 0, 1, 0, shift]
    thisLayer.applyTransform( shiftMatrix )

OK, recap. Our function looks like this:

def randomVerticalMove(thisLayer, maxShift=100):
    shift = random.randint( -maxShift, maxShift )
    shiftMatrix = [1, 0, 0, 1, 0, shift]
    thisLayer.applyTransform( shiftMatrix )

And our loop is now expanded to this:

for thisLayer in selectedLayers:
    slapNodesRandomly(thisLayer, maxX=70, maxY=70)
    randomVerticalMove(thisLayer, maxShift=200)

In the last line, we call the randomVerticalMove() function, and pass two arguments: the layer we are just looping through, and the maximum shift we allow. To make it more fun, I chose 200 instead of the default 100.

Affine Transformations: Rotate

How about rotating? Sounds cool, but there is no rotation in the matrix, right? No problem if you remember your last year of math at school: rotation can be achieved through a combination of shearing horizontally and vertically plus some compensatory scaling. If you like, you can dive back into trigonometrical calculations, but I will cut the story short and give you the matrix: For rotating around the origin point by an angle a, you need the matrix: cos(a), −sin(a), sin(a), cos(a), 0, 0.

So, all is set now, right? All we need to do is calculate the angle, fill it into that matrix, and apply the affine transformation, done. Well… not quite. Remember all transformations are happening around the origin point. If we want to rotate around a better pivot point, like the center of the layer bounds, we need to shift the whole layer content onto the origin point, then rotate, and finally shift everything back to its original position. Makes sense? OK, here we go:

def rotateLayerRandomly(thisLayer, maxAngle=5):

First thing we need to do is find the center of the layer and move it onto the origin point. Luckily, the layer has an attribute called bounds, and bounds has two attributes, origin and size. Digging deeper, we find that origin has x and y as attributes, while size has both width and height. To calculate the center, we need to start at the origin point, and add half the width and half the height. This is what the following two lines do:

    xCenter = thisLayer.bounds.origin.x + thisLayer.bounds.size.width * 0.5
    yCenter = thisLayer.bounds.origin.y + thisLayer.bounds.size.height * 0.5
    shiftMatrix = [1, 0, 0, 1, -xCenter, -yCenter]
    thisLayer.applyTransform( shiftMatrix )

And the two lines after that construct the transformation matrix for shifting the layer content on top of the origin point.

Now it is time to rotate. In other words, we need to first calculate a random angle between the negative and positive maximum, then construct and apply another transformation matrix with the sine and cosine of the angle. The random number part is easy:

    angle = random.randint( -maxAngle, maxAngle )

Now, how do we get the cosine and sine for that angle? In Python, there is a module for anything beyond the most basic mathematics, and it is called math. We can import it like we imported random before, and then we can access its functions. First, we need to expand the import line to also include the math module:

import random, math

Let’s see what math has in terms of trigonometric functions. In a new Python window in TextEdit or SublimeText, or the Glyphs Macro Window, type this and run it:

import math
help(math)

And you will see a lot of output, amongst which the definitions of two functions called sin() and cos(). To narrow down the help output, run this:

import math
help(math.sin)
help(math.cos)

And you should receive this output:

Help on built-in function sin in module math:

sin(...)
    sin(x)

    Return the sine of x (measured in radians).

Help on built-in function cos in module math:

cos(...)
    cos(x)

    Return the cosine of x (measured in radians).

OK, so that means that we can run math.cos(x) and math.sin(x), provided x is measured in radians. Wait a minute, our angle is measured in degrees, so we need to convert it to radians first. Luckily, there is also a radians() function in the math module. To find out more about it, we can run help(math.radians):

Help on built-in function radians in module math:

radians(...)
    radians(x)

    Convert angle x from degrees to radians.

Phew. So, let’s continue in our rotateLayerRandomly() function. First we need to make the radians conversion, then build and apply the matrix:

    angleRadians = math.radians( angle )
    rotationMatrix = [math.cos(angleRadians), -math.sin(angleRadians), math.sin(angleRadians), math.cos(angleRadians), 0, 0]
    thisLayer.applyTransform( rotationMatrix )

Did we forget anything? Of course! We need to move the whole thing back from the origin to its original position! In other words, the reverse of what we did before:

    shiftMatrix = [1, 0, 0, 1, xCenter, yCenter]
    thisLayer.applyTransform( shiftMatrix )

But I think that’s it. Let’s recap. Here is our function:

def rotateLayerRandomly(thisLayer, maxAngle=5):
    # move on top of origin point:
    xCenter = thisLayer.bounds.origin.x + thisLayer.bounds.size.width * 0.5
    yCenter = thisLayer.bounds.origin.y + thisLayer.bounds.size.height * 0.5
    shiftMatrix = [1, 0, 0, 1, -xCenter, -yCenter]
    thisLayer.applyTransform( shiftMatrix )

    # rotate around origin:
    angle = random.randint( -maxAngle, maxAngle )
    angleRadians = math.radians( angle )
    rotationMatrix = [ math.cos(angleRadians), -math.sin(angleRadians), math.sin(angleRadians), math.cos(angleRadians), 0, 0 ]
    thisLayer.applyTransform( rotationMatrix )

    # move back:
    shiftMatrix = [1, 0, 0, 1, xCenter, yCenter]
    thisLayer.applyTransform( shiftMatrix )

I added comments for clarity. And our loop now looks like this:

for thisLayer in selectedLayers:
    slapNodesRandomly(thisLayer, maxX=70, maxY=70)
    randomVerticalMove(thisLayer, maxShift=200)
    rotateLayerRandomly(thisLayer, maxAngle=15)

And, our last recap for now, the whole script looks like this now:

#MenuTitle: Glyph Shaker
# -*- coding: utf-8 -*-
__doc__="""
Goes through all selected glyphs, slaps their nodes around, rotates them a little, and shifts them up or down a little.
"""

import random, math
random.seed()

def slapNodesRandomly(thisLayer, maxX=50, maxY=0):
    for thisPath in thisLayer.paths:
        for thisNode in thisPath.nodes:
            thisNode.x += random.randint( -maxX, maxX )
            thisNode.y += random.randint( -maxY, maxY )

def randomVerticalMove(thisLayer, maxShift=100):
    shift = random.randint( -maxShift, maxShift )
    shiftMatrix = [1, 0, 0, 1, 0, shift]
    thisLayer.applyTransform( shiftMatrix )

def rotateLayerRandomly(thisLayer, maxAngle=5):
    # move on top of origin point:
    xCenter = thisLayer.bounds.origin.x + thisLayer.bounds.size.width * 0.5
    yCenter = thisLayer.bounds.origin.y + thisLayer.bounds.size.height * 0.5
    shiftMatrix = [1, 0, 0, 1, -xCenter, -yCenter]
    thisLayer.applyTransform( shiftMatrix )

    # rotate around origin:
    angle = random.randint( -maxAngle, maxAngle )
    angleRadians = math.radians( angle )
    rotationMatrix = [ math.cos(angleRadians), -math.sin(angleRadians), math.sin(angleRadians), math.cos(angleRadians), 0, 0 ]
    thisLayer.applyTransform( rotationMatrix )

    # move back:
    shiftMatrix = [1, 0, 0, 1, xCenter, yCenter]
    thisLayer.applyTransform( shiftMatrix )

# loop through all selected layers:
selectedLayers = Glyphs.font.selectedLayers
for thisLayer in selectedLayers:
    slapNodesRandomly(thisLayer, maxX=70, maxY=70)
    randomVerticalMove(thisLayer, maxShift=200)
    rotateLayerRandomly(thisLayer, maxAngle=15)

OK, I admit that I cleaned up some more: I updated the doc string, I moved the selectedLayers assignment to right in front of the loop, and I added some comments here and there.

And you see I have been a little inconsistent when it comes to extra spaces I leave between parentheses or brackets and their respective content. It doesn’t really matter, it is a matter of coding style, and I sometimes leave extra spaces for increased legibility. But I have been accused of sloppiness because of this, so you may want to be more consistent about it than I am.

And let’s see what it does to a font: Save the script, open a font you never really liked that much, select a few glyphs, and run the Glyph Shaker script again from the Script menu. This is what happens:

Ha, cool. Experiment with the values you pass to the functions and give those fonts hell. Have no mercy.

Update 2017-06-19: Fixed sin() and cos() calls in two samples (thx Jeff Kellem).
Update 2018-12-26: Corrected number values in the explanation of slapNodesRandomly(): maxX has a default of 50, not 100.

Font names are important because they determine font menu grouping and ordering, which is crucial for the way your fonts will appear to your users. Naming your font family can be a little tricky, so you will be happy that we shared our best tips in the following tutorial.

It is important to adopt a good practice in font naming. What makes it challenging is the fact that the font names are stored in six different places in the font. Or actually, a few more places. Which makes it even more complicated. Historically grown, you know.

Oh, and different apps read the font naming information in different ways. Following is what we suggest as best practice.

Family Name and Subfamily (Style) Name

Basically, fonts with the same Family Name can be grouped together somehow in a user interface. How exactly this is done, of course, depends on the software that employs your fonts. You can set your Family Name in File > Font Info > Font > Name:

The individual fonts of your family need to be differentiated by their Subfamily Name (a.k.a. Style Name), which is set with the Name field in File > Font Info > Exports. Typical style names are: Regular, Italic, Bold, Medium, Light Italic, Display Bold, Caption Italic, etc. In other words, some combination of keywords for:

• Weight: Thin, Light, Extralight, Regular, Medium, Semibold, Bold, Extrabold, Heavy, Black, etc.
• Width: Compressed, Condensed, Extended, Expanded, etc.
• Slope: Italic, Oblique, Upright Italic, Backslant, etc.
• Optical Size: Display, Text, Caption, Small

Of course, you can use any style name. If it makes sense for your design, you can also call it Felt Tip or Hatched or Outline or anything you like. Western Latin accents in the name should not cause much of a problem in modern software.

If you want some instances to have different family names than the default family name (the one set in File > Font Info > Font > Name), you can add a general property called Family Names to the respective instances in File > Font Info > Exports.

So, you would end up with a naming scheme like this:

Localized Names

For maximum compatibility, however, there is something to be said for keeping the Family Names and Style Names plain-ASCII, English, and short. If you want to go beyond that, and use non-ASCII characters (e.g., for a Japanese or Armenian or Czech name), it is a good idea to add localized names.

To localize your family name, go to File > Font Info > Font, add a general property by clicking on the plus button in the General section, choose Family Names from the pop-up, then pick a language and set the name:

Add an entry for every language in which you want the name to appear different from the default Family Name. The choice of languages is limited, because the spec was written a long, long time ago in a galaxy far, far away. It supports Icelandic and Afrikaans, Mongolian, Malay and Macedonian, it can even differentiate between Flemish and Dutch, but it does not know every language. Sorry if the one you need is not in the menu, but there is not much we can do about it.

To localize your style name, add the Style Names general property to the respective font instances in File > Font Info > Exports. Adding languages works exactly the same as for Family Names. Speaking of which, you can also localize the family name in the exporting instances, i.e., the general setting Family Names is also available in File > Font Info > Exports > General. This can be useful if you have custom family names for some instances, and need to localize those too.

While we’re at it, you can also localize many other entries, such as the designer and manufacturer names for example. How? With the respective general properties, of course: Designers and Manufacturers in our example. If an added entry is localizable, it will sport a language menu and allow you to add all the language variants you have always wanted for your font.

Style Linking

You can set up family relationships between individual fonts with something called style linking. You can define one instance as the Bold, the Italic or the Bold Italic of another instance. This is pretty easy with the Style Linking section in File > Font Info > Exports. All you need to do there, is activate the Bold and/or Italic checkbox, and fill in the name of the related instance, e.g.:

With style linking, you can create so-called ‘RIBBI families’. RIBBI is short for Regular, Italic, Bold and Bold Italic. This seems a bit limiting, but its purpose is to enable the Bold and Italic buttons and keyboard shortcuts in Office software. If you do this right, you can use Cmd-B in TextEdit to switch back and forth between the Regular and the Bold, or Ctrl-I in Word on Windows for toggling between the Upright and the Italic. Adobe InDesign uses Cmd-Shift-B and Cmd-Shift-I for the same purposes, by the way.

In other words, style linking can only create a relationship between four styles, not more. Another thing to consider is that linked styles will not be displayed in Microsoft Office font menus. Only the Regular is visible, the linked Bold, Italic or Bold Italic styles are exclusively accessed through the B and I buttons (or the respective keyboard shortcuts). We therefore recommend the following strategy for style linking:

• The ‘Bold’ instance is the Bold of the ‘Regular’.
• The ‘Italic’ instance is the Italic of the ‘Regular’.
• The ‘Bold Italic’ instance is the Bold and Italic of the ‘Regular’. (Careful here: not the bold of the italic or the italic of the bold.)
• All other italics are the Italic of their respective upright, e.g., ‘Semibold Italic’ is the Italic of ‘Semibold’.
• For all remaining uprights, leave these settings blank.

So, if we do everything right, our font family set up looks like this:

Naming for Windows and Office Software

Microsoft Word currently focuses on Family Name and Subfamily (Style) Name, or alternatively, on the WWS Family Names and WWS Subfamily Names, if present. WWS stands for Weight, Width and Slope.

The Microsoft font menu assumes a family model where the only possible members of a font family are Regular, Bold, Italic, and Bold Italic, i.e., the RIBBI styles between which style linking is set up as described above. Anything else that isn't one of these four must be considered a separate family. Therefore, Microsoft officially recommends this naming strategy:

And so on. In other words, the Subfamily (Style) Name (ID 2) can only ever be one of the RIBBI styles. All the other info about Weight, Width and Slope goes into the Family Name (ID 1). What you can also see, of course, is that this is very different from the table you can see further above. There are a few problems with this. It is hard to handle. You have to add an awfully high number of familyName parameters, and what’s worse, you would lose your oversight in File > Font Info > Exports, because most of the style names are the same. Also, what may be right for Word, may not be ideal for other apps, like DTP programs.

But wait a minute…

There’s good news: You don’t have to do this. Glyphs will automatically take care of this at export time. Based on your style linking info, Name IDs 1 and 2 will be set accordingly in the Windows names of the Naming Table. (That’s right, the info in the name table is stored twice, once for Mac, once for Windows. Don’t even ask why.) That is why, from here on, I will not refer to the default family and style names (as entered in Font Info) by their Name IDs, because it’s more complicated than that as you can see.

If, for whatever reason, this automation does not work, i.e., the B and I buttons in Word do not produce the expected styles, you can take control of the style mapping with a general property called Style Map Family Names. This quote from the property pop-up says it all:

Style Map Family Names: Family name used for bold, italic and bold italic style mapping. You can use this to create subfamilies within larger font families. ‘Up to four fonts can share the Font Family name, forming a font style linking group (regular, italic, bold, bold italic – as defined by OS/2.fsSelection bit settings). Glyphs uses the entries in Style Name field and in the Style Linking section of the instance for linking the four individual weights.

Again, you will most likely not need the property, and even less so to localize it. But just in case.

WWS Names: Name IDs 21 and 22

The WWS names, also known as Name IDs 21 and 22, are only needed:

• if the family has style variants other than weight, width, and slope, i.e., if the font has a non-WWS axis;
• and only for those fonts that have a non-normal value for that non-WWS axis, i.e., if the style cannot be expressed purely with weight, width and slope.

Let’s suppose we want to expand our font family with optical size variants, like ‘Subhead’, ‘Display’, ‘Caption’, etc. The fonts we have seen in the tables above would not require WWS names because they are not non-normal on our new Optical Size axis. But the new fonts we add, that take up a special, non-normal position on our Optical Size axis, they do need the WWS names.

And the way this works is that you create separate families with the non-normal names, and put those family names into ID 21, but keep all the weight, width and slope info in ID 22. So, Name ID 22 is not only for RIBBI names, but for anything that falls into the weight, width or slope category, like Medium Extended Italic or Bold Condensed Oblique.

How do you do that in Glyphs? Easy. You add the appropriate custom parameters for the respective fonts in File > Font Info > Exports. For the WWS Family Name, you use the general property WWS Family Name, and for the WWS Subfamily Name, you add a WWS Subfamily Name. Who would have guessed.

Note 1: Inclusion of IDs 21/22 should correlate exactly with the state of OS/2.fsSelection.bit8, if you know what that means. If you don’t, don’t worry, Glyphs takes care of this automatically.

Note 2: For a case like MyFontFamily Compressed, where the style name is purely expressible with WWS, name IDs 21/22 are not required, remember? But actually, the spec does not preclude including IDs 21 and 22, provided this fsSelection bit 8 is set. So if you feel like it and have a lot of time to kill, you can add them everywhere. But really, finish early and have an ice cream instead. If you want to take control of fsSelection bit 8 yourself, add the Has WWS Names parameter to your instance: According to the OpenType specification, this bit indicates that ‘the font has “name” table strings consistent with a weight/width/slope family without requiring use of “name” IDs 21 and 22.’ Keep in mind that this makes sense only if the naming of your font already adheres to the WWS scheme.

Naming for Adobe Menus

Fonts in Adobe menus are sorted into submenus based on their Family Name. This can be overridden by the Typographic Names, also known by their deprecated name, the Preferred Names (Name IDs 16 and 17). So if you don’t like the submenu arrangement, you can make your own submenus with Typographic Family Names and put the rest of the respective font name into Typographic Subfamily Names. Both of them are general properties, which you can add by pressing the plus button in the top right corner of the File > Font Info > Exports window.

Inside the submenu, the fonts are sorted by, and in this order:

1. by the width class,
2. by the weight class,
3. by the slope (upright or italic),
4. and finally, alphabetically by the style name.

You can set the width class by choosing from the Width menu (1), a weight class from the Weight menu (2), the slope with the Italic button (3), and the alphabetic order, of course, with the Style Name (4).

If you need to differentiate further when it comes to width and weight classes (because several of the options will yield the same number displayed to the right of the menu), you can directly set the numbers for ordering in the general properties Width Class and Weight Class. E.g., if you need an extra weight between Regular (400) and Medium (500), you would enter 450 in Weight Class:

That means that you can do anything you like! If you want all the fonts to be in the same submenu, you just make sure that the Typographic Family Names are the same for all fonts. If, however, you want to have your fonts in different submenus, you can differentiate with the same parameter.

Just keep in mind that you only need to set these parameters if they differ from the Family Name and Style Name entries. Otherwise they are not necessary. In other words, only use the Preferred Names to override the defaults established by Family and Style Name. Needless to say, it makes no sense to override them with the same values.

Example: Let’s say you have a Weight and a Width axis. And let’s further assume that you have 5 widths and 9 weights, i.e., 45 fonts in total. Imagine that submenu, whoa. You have two choices:

(A) You want to keep all 45 fonts in one menu. Then you don’t have to change anything in the above setup. Congratulations, you can go and have a drink now.

(B) You want to have the font in five different submenus for the five widths. That way, you clutter your font menu with five entries instead of one entry, but at least your submenus will only have 9 entries each instead. In that case you would use Typographic Family Names for all non-normal widths, e.g., ‘MyFont Compressed’, ‘MyFont Condensed’, ‘MyFont Semiextended’, and ‘MyFont Extended’. For the normal width, the ‘normal’ Family Name ‘MyFont’ suffices. Thus, it does not need a Typographic (a.k.a. Preferred) Family Name.

Windows vs. Mac: Full Name vs. Compatible Full Name

Windows uses Name ID 4 (‘Full Font Name’ or ‘Full Name’) for displaying the full name of the font, e.g., in a menu. Usually it consists of the family name, followed by a space, followed by the subfamily (style) name. This is also how Glyphs autocalculates the ID 4 entry. You can override it with a Name Table Entry custom parameter (see further below). So far, so good.

The Mac also uses Name ID 4 for this purpose. That is, unless there is Name ID 18 (‘Compatible Full Name’) present in the font. In other words: If, for whatever reason, you cannot live with the ID 4 name in your Mac menus, you can have a different name by adding a general property called Compatible Full Names to your instance in File > Font Info > Exports.

Needless to say, only do this if you have a really good reason. Using Compatible Full Names may break cross-platform interoperability of documents. You have been warned.

Compatible Name Table

I told you above that Glyphs automatically takes care of juggling the Name table entries into their right spots, so that stuff works best in Adobe apps, as well as in Microsoft Office and CoreText apps on the Mac. Most apps are covered this way.

Occasionally, however, you will have a customer that complains. Especially users of Quark XPress and legacy versions of FontExplorer. If you hear the complaint that the font family is not correctly grouped in those apps, you can use a custom parameter called Compatible Name Table. It will cause Glyphs to export a legacy-style name table.

The font family will then be grouped properly in Quark XPress and FontExplorer. However, it will mess up family grouping in other apps, including Microsoft Office. Can’t have it all, I am afraid.

The PostScript Names

The PostScript names are a legacy from the PostScript Type 1 era. Some apps, and some (especially PostScript-based) file formats will use the PostScript Font Name (Name table ID 6, in the latest version of the specification simply ‘PostScript Name’) for storing font information in documents. The PostScript Full Name (Name table ID 4, now simply ‘Full Font Name’) is intended for the human reader only. Again, both are set automatically by Glyphs, and you will most likely not have any problems if you simply let the app do its magic. So you can jump to the next headline in this tutorial unless you have a really good reason to set it yourself.

The PostScript Font Name (‘PostScript Name’, ID 6) can be set in File > Font Info > Exports with a general property called Font Name. It is tricky for two reasons: the length of the name, and the character restrictions. Technically, the maximum length is 127 characters, which should be good enough for almost all fonts. Some legacy software like the Adobe Type Manager (ATM), however, only considers the first half, i.e., 63 characters. In other words, old apps may not be able to differentiate between two fonts, or even malfunction, if the first 63 characters of their PostScript Font Names are the same. The good news: If you do not care about legacy software, you can ignore this restriction. But if you do care about legacy compatibility, it can get even worse: early PostScript interpreters cannot have more than 29 (yes, twenty-nine) characters. Ugh.

In terms of character restrictions, your PostScript Font Name can only contain 7-bit ASCII without control characters, without space, and without these 10 characters: [](){}<>/% because they are reserved in the PostScript language. The hyphen - is reserved for connecting family and subfamily (style) name. In other words, you get to use only these characters:

!"#$&'*+,-.0123456789:;=?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_@abcdefghijklmnopqrstuvwxyz|~

That means that MyFont Condensed Extrabold Italic will turn out to be MyFont-CondensedExtraboldItalic, which is 31 characters long. Let’s further assume that your client demands that you have to support that image setter from 1988, which can handle no more than 29 characters. In order to reach the length limit, you can abbreviate the part that makes up the style name to CdXBdIt. The complete font name, thus, turns into MyFont-CdXBdIt, which counts no more than 14 characters. Now you can dust off those machines from the museum again.

In Tech Note #5088, Adobe recommends these abbreviations for style names:

In case you were wondering, ‘Nord’ and ‘Nord Italic’ were the first released weights of Roger Excoffon’s famous Antique Olive typeface family in 1960. They are wide and very bold cuts. Since a digital version of it was in the Adobe Library, it was added to the list when Adobe put it together. To my knowledge, this is the only occurrence.

And there is the PostScript Full Name (‘Full Font Name’, ID 4), which can be set with the general property Full Name, again in File > Font Info > Exports > General. Here, human-readability is key, since it is the complete name of the font as it is supposed to appear to the user, and is thus allowed to contain spaces. According to Adobe, it should be ‘suitable for display in font menus’.

So we are completely free to write what we want, right? Well, not quite. According to Adobe Tech Note #5088, some systems match the font’s Family Name against the PostScript Full Name ‘for sorting into family groups.’ Therefore, the PostScript Full Name should start with the Family Name. The PostScript Full Name ‘is completed by adding style attributes — generally in this sequence: weight, width, slope, optical size’ (Adobe Technote #5088), e.g., ‘Bold Extended Italic Display’, or ‘Medium Condensed Oblique Caption’, or ‘Semibold Oblique’, or ‘Compressed Poster’, or ‘Light’.

Again, set the (PostScript) Font Name and Full Name only if you really feel an uncontrollable inner urge to do so, and would run amok if you cannot do it yourself. Otherwise, just forget about it and let Glyphs set both of the PostScript names, since these are so easily calculated anyway.

Name Table Entries

If you know what you are doing, and nothing can scare you anymore, you can also do the whole Name Table yourself. You can set each entry of the Name Table for all sorts of languages in all sorts of encodings on all sorts of platforms. All you need to do, is go to File > Font Info > Exports, pick an instance, add the Name Table Entry custom parameter, and then use one of the following structures for its value:

nameID; nameString
Example: 4; MyFont Bold Italic (Windows English Full Name)

In this case, platformID will be assumed as 3 (Windows), and successively, encID as 1 (Unicode), and langID as 0x0049 (Windows English).

nameID platformID; nameString
Example: 4 1; MyFont Bold Italic (Mac English Full Name)

If platformID is specified as 1 (Mac), then both encID and langID will be assumed as 0 (MacRoman and Mac English).

nameID platformID encID langID; nameString
Example: 4 3 1 0x040C; MaPolice Gras Oblique (Windows French Full Name)

If platformID is specified as 1 (Mac), then encID can be a number between 0 and 32, and langID between 0 and 150 (see Macintosh platform-specific encoding and language IDs).

If platformID is specified as 3 (Windows), encID can be between 0 and 10, and langID must be a hex number below 0x8000 (see Windows platform-specific encoding and language IDs).

The platformID can either be 1 for Macintosh or 3 for Windows. The optional encID and langID represent either Windows or Macintosh encoding and language IDs, depending on the platformID. They must be numbers between 0 and 65536, and can be entered in decimal, octal or hexadecimal form. The AFDKO Syntax specification stipulates that ‘decimal numbers must begin with a non-0 digit, octal numbers with a 0 digit, and hexadecimal numbers with a 0x prefix to numbers and hexadecimal letters a-f or A-F.’

Between you and me, the only two platforms that really matter are platform ID 1 Macintosh and platform ID 3 Windows, or actually, only ID 3 Windows, really. The other platform IDs 0 Unicode, 2 ISO and 4 Custom are hardly, if at all, in use. One of them, 2 ISO, has even become officially deprecated. Still, be careful if you set Name Table entries yourself, especially if you choose the long form of the parameter, because each platform has its own unfathomable list of encoding and language IDs. Haha, they are coming to take me away, hahaha. So, if you really want to do this yourself, you will find yourself surfing to this web page a lot: Microsoft OT Spec: The Naming Table, which lists all the encoding and language IDs your font-geek heart desires.

Here is a quick table of the Name Table entries you can set with <nameID>, except the ones marked with an asterisk. The links take you to the Microsoft spec page:

For most of these entries, there are better ways to set them, usually a text entry field in the UI or a dedicated custom parameter. And if you do, you can usually get away by setting the Windows name only. In other words use the short form of the parameter <nameID>; <nameString> and you’re done.

And again, only do this if for some reason the Name Table produced by Glyphs does not work for you, and if you know what you are doing. Setting them yourself just for the sake of doing it yourself will likely break something.

Many thanks to Rob McKaughan from Microsoft for providing much of the information explained in this tutorial. Some passages are quoting Rob directly.


Update 2017-12-17: Fixed typos, added an example for the preferredFamilyName (Typographic Family Names) parameter.
Update 2017-12-17: Added paragraph about Antique Olive Nord. Merci bien, Jean François Porchez! Added some infos about Name Table Entries and PostScript Names in EOTs. Thank you, Phil Garnham!
Update 2018-07-05: Removed some old limitations of the Name Table Entry parameter, because you can now set all Name IDs with the parameter.
Update 2019-03-19: Corrected typos; replaced MaFonte for MaPolice, and Mac Roman for MacRoman (thx Nathalie).
Update 2019-11-14: Updated the wording to the most recent spec version (thx Joachim).
Update 2020-11-13: Updated for Glyphs 3.

Devanagari, used for languages such as Hindi, Marathi, Nepali, and many more, is the widest used script in India. While each designer might have their own workflow, this tutorial illustrates our recommended step-by-step process to build a Devanagari font by utilizing all of Glyphs’ cool features!

Setting up a Devanagari font file

When you create a new file in Glyphs (File > New, Cmd-N), it will open a window with Latin characters by default. There are two ways to add glyphs for Devanagari – one through Glyph > Add Glyphs (Cmd-Shift-G), or from the sidebar under the Languages > Devanagari section. Right-click on the subcategories inside Devanagari to see a list of glyphs included in each section then you can select the ones to add to the font:

You can see that all Devanagari glyphs have descriptive glyph names and a -deva suffix. This makes it possible for the app to determine the script of the glyph and automatically build the appropriate OpenType code later on.

The First Step

Let's start with the most basic element of a Devanagari letter, the vertical stroke as found in aaMatra-deva. This defines the most basic proportions of our Devanagari letterforms, and it is used in most glyphs. So it would be great if we could design it once, and use it as a component in all the other glyphs needing it. You will find this character listed in the sidebar under Languages > Devanagari > Vowels. Or you can manually add it by typing Cmd-Shift-G, then, in the upcoming dialog, aaMatra-deva and pressing the Generate button.

You can also go ahead and add a value for the shoulder-line with the shoulderHeight custom parameter in File > Font Info > Masters (cmd-I). This will help the placement of anchors in not only the aaMatra-deva, but many other glyphs as well.

A note about spacing: Devanagari usually has a connecting headline, so you will probably want to extend the headline out slightly, so the sidebearings have negative values. You can define a standard value here and it will apply to many glyphs later on as well. Don’t worry, if you change your mind later, it’s very easy to update everything at once.

Setting Anchors

It is never too early to start thinking about anchors. Most vowel and intonation marks will align in the same place relative to the vertical stem, so we can simply add anchors to the aaMatra-deva and they will be automatically copied to any glyph using this as a component. With the shoulderHeight defined, you only need to run Glyph > Set Anchors (Cmd-U), and the anchors will be automatically added at the correct vertical height. You may need to move them horizontally depending on your design.

Building Compounds from Half-Consonants and Half-Forms

Now we can prepare the components needed for the consonants. Most of the consonants are constructed with a half-form connected to the aaMatra-deva. These half-forms are not only used to form the full consonants, but also to build conjuncts – the ligatures of two or more consonants where the inherent vowel aaMatra-deva has been deleted (e.g. ‘pepper’ = पेप्पर). More about conjuncts later, let’s first design the p-deva, which is the half-form of pa-deva. You may now want to go ahead and add the half-forms from the aptly named Halfform section in the sidebar.

To create the full consonant pa-deva, we can generate that glyph (via Glyph > Add Glyphs…, Cmd-Shift-G), then add the p-deva and aaMatra-deva as components by choosing Glyph > Add Component (Cmd-Shift-C) for both of them. If you are not happy with the alignment, you can just adjust the right sidebearing of the p-deva to look good next to an aaMatra-deva, then the pa-deva should automatically match perfectly.

Using this approach, we can design much of the basic Devanagari consonants. Let’s go ahead and add some more in the same way:

Completing the Basic Consonants

You will notice that not all consonants can be built from half-forms, e.g., glyphs like ka-deva, pha-deva, and ha-deva. These will need custom designed full forms. In cases like this, we generally draw the full forms first, then use those as the basis for their half forms.

There is also a small set of hanging consonants that do not have normal half-forms: tta-deva ttha-deva dda-deva ddha-deva da-deva nga-deva. Instead of turning into a half-form, they receive a ‘halant’ at the bottom (also referred to as ‘virama’). In other words, now may be a good time to draw the halant-deva glyph. Find it in the sidebar under Languages > Devanagari > Marks. Do not forget to hit Cmd-U to give the halant an anchor.

Once you have the hanging consonants and the halant in your font, you can create the remaining consonants: Choose Glyph > Add Glyphs… and paste this:

tt-deva tth-deva dd-deva ddh-deva d-deva ng-deva

Then press Generate. I.e., the same glyph names, but without the a at the end. Glyphs is smart enough to create them right away as compounds of the respective hanging consonant and the halant.

Spacing Consonants and Kerning Groups

We can start spacing our glyphs by switching to the Text tool (T) in an Edit view. Let’s space the tta-deva next to an aaMatra-deva:

We can go ahead and define the right kerning group for all the consonants using aaMatra-deva at this stage. As for the left groups, you can identify similar left side shapes and define those as well; be sure to also do it for the half-forms.

Conjuncts

Conjuncts are another important element needed to correctly render the Devanagari script. The way you choose to form these will vary depending on your design. Generally, most can be written horizontally/linearly, as a combination of a half-form and full consonant. Others occur either vertically stacked or combined into a more complex letterform – these are referred to as ‘akhand conjuncts’.

In this comparison, you can see how some linear conjuncts are built with default half-forms, and then, their modified, custom versions to make nicer clusters:

If one considers any two, three, four or more consonant combinations, there can be thousands of combinations. Sanskrit requires many conjuncts – and many of them are of the akhand variety. But Hindi, Marathi and other modern languages use conjuncts less frequently. So if one were to support advanced Sanskrit, the number of akhand conjuncts to be designed could easily be a few thousand. Hence, the function of the font will decide the character set. If you are looking to support modern Hindi, Marathi, Sindhi, Nepali, etc., the number of conjuncts required could be considerably less.

Instead of designing all the thousands of possible combinations, Glyphs allows for the linear conjuncts to be automatically composed from the half-forms and full-forms we designed earlier. It will be up to the style and requirements of your design to decide which, or how many, linear conjuncts you will custom-design. In some cases you may need very few, other times you may need lots. There is no easy way around it, you will need to test all the combinations to see which look good by default and which should have custom linear conjuncts.

Generating the OpenType Features

As alluded to earlier, Devanagari requires a lot of complicated OpenType code to get it to render correctly. Fear not, Glyphs can generate it all automatically! Open File > Font Info > Features (Cmd-I). Now just press the Update button and Glyphs will write all the OpenType code needed to preview what you have so far.

If you haven’t noticed already, in the Edit view you can insert any character by pressing Cmd-F. Try inserting a consonant, a halant, and another a consonant. Now look in the lower left corner of the Edit view, and click the Features button: The features and languages your typeface supports are now listed under their scripts. Select Devanagari to see the OpenType code in action:

Different Forms for ra-deva

Now let’s move on to the shapeshifting letter Ra. In Devanagari, the Ra can take on four different forms depending on its context. If it is first in a cluster, it becomes a Reph, and is placed over the vertical stem of the last full-form consonant in the cluster.

If the Ra is placed after consonants with a vertical stroke, it will turn into a ‘leg’, attached to the vertical stem of the preceding consonant:

But wait, there’s more. If the Ra combines with a consonant without a vertical stroke, it becomes a Rakar. This applies primarily to tta_ra-deva ttha_ra-deva dda_ra-deva ddha_ra-deva cha_ra-deva:

But wait, there’s even more! In Marathi, the Ra can also take on the form of an ‘eyelash’:

Phew! Let’s quickly recap these variations.

The Reph and the Rakar are easy. Just create reph-deva and rakar-deva, draw your shapes, and place the anchors with Cmd-U. By the way, both reph-deva and rakar-deva are in the sidebar under Languages > Devanagari > Marks.

The ‘leg’ form conjuncts takes a bit more effort. Let’s first design rakar-deva.leg (note the dot suffix .leg) to use as a component. This one is not in the sidebar, so just create it manually with Glyph > Add Glyphs… (Cmd-Shift-G). Once we have done that, we can place a _leg anchor in it: right-click in the canvas, choose Add Anchor from the context menu, then type the anchor name:

This leg form of Ra can also appear in the middle of clusters. For that, we should also design ‘half-conjuncts’. Such a concept does not exactly exist in Devanagari, but by utilizing these new glyphs as components, we can dynamically create numerous custom looking conjuncts – without actually having to design every conceivable permutation individually.

To have the rakar-deva.leg automatically connect to the consonants, we should place a leg anchor on all the half-consonants. This way, they will show up as a combination with the half-forms as well as the full-forms. You can then generate the conjuncts from the sidebar, or with Glyph > Add Glyphs… (Cmd-Shift-G) and manually typing names. But pay attention because correct naming of these conjuncts is essential for Glyphs to construct the compounds and automatically generate the OpenType feature code.

It’s important to note that the nomenclature of Ra conjuncts is slightly different from the other conjuncts. Name the conjuncts the way they look. In the case of the text pa-deva halant-deva ra-deva we see a pa-deva with a Ra (the Ra has the form of a leg, but it is a Ra none the less). Therefore we call the conjunct pa_ra-deva. Once you make the conjunct glyphs using the anchor, you might want to change the position and angle of the leg depending on the consonant it appears with. In some cases, you may have to decompose the components to ensure that the leg does not clash with the consonant.

Let’s make the ‘half-conjunct’ for pa-deva halant-deva ra-deva halant-deva. Following the visual-appearance model of naming, our new glyph should be named p_ra-deva:

Creating half-conjuncts will speed up the generating of the full-form akhand conjuncts. And it will allow for more dynamic building of complex linear conjuncts, like this fake one:

Nukta

This is working great so far but what about the Nukta (nukta-deva)? Begin by drawing this little dot, or using another existing dot as a component. Then hit Cmd-U to add the appropriate anchor.

Luckily for us, anchors found inside components will get used, they ‘shine through’. This usually saves a lot of work (just think about the aaMatra-deva). But sometimes the anchor position in a component will cause problems with more complicated conjuncts. Then you can override the anchor by placing an anchor with the same name in the compound.

Now let’s look at this p_ra-deva that we just made. In cases like these, we can avoid this overlap by adding a nukta anchor in the p_ra-deva glyph. Now anytime you use this component, the new anchor will always override the nukta that shines through from the p-deva:

Creating Vowel Marks

Devanagari vowel marks, or ‘matras’, are forms of vowels that appear in combination with consonants and conjuncts. Most will be positioned automatically with the help of top and bottom anchors. We took care of this already when we created the stem anchor at the beginning:

Just like with the nukta anchor, you should check each glyph and the vowel positions, because on certain combinations, they will need to be adjusted.

iMatra-deva

The i matras are another exception to the rule. They need their own special imatra anchor to work properly. (Hint: iiMatra-deva gets an iimatra anchor.) Depending on your design, you might choose to create any number of iMatra-deva length variations. The iMatra-deva glyph should extend to connect with the vertical stem of the modified letter, and this can vary significantly because of the numerous conjunct possibilities. But this is also a stylistic decision, so you may want more or fewer options.

Create as many iMatra-deva variants with number suffixes as you feel necessary: iMatra-deva.001 iMatra-deva.002 iMatra-deva.003, etc., and give each of them an imatra anchor (Cmd-U). Glyphs will use these anchors to calculate which iMatra-deva variant is best fitting to your top anchors in your main consonants and conjuncts when it is generating the OpenType code. To check on the result, see the pres feature in File > Font Info > Features.

So, that is an overview of our recommendations for developing Devanagari fonts. Gone are the days of being overwhelmed by complicated OT coding, you can now just focus on making beautiful typefaces and let Glyphs do the heavy lifting in production.

Guest tutorial by Kimya Gandhi and Rob Keller (Mota Italic, Mumbai).
SAMPLE FONT: VESPER DEVANAGARI BY MOTA ITALIC

Update 2020-11-13: Glyphs 3 website updates.

Variable Fonts open a whole new world of possibilities. Creating them is a breeze in Glyphs.

What are Variable Fonts?

If you have not read John Hudson’s excellent introductory article, stop right now what you are doing, and read it. No, really.

Step 1 Define Axes

In File > Font Info > Font > Axes, add an axis by clicking on the plus button:

Double click its Value field. In the upcoming dialog, click on the gear buttons to add and remove axes. Pick one of the predefined axes (Weight, Width, Italic, Slant, Optical Size), or make up your own.

You can redefine your axes any time, and in the current implementation, you can define up to 6 axes. In this example, I will stick to one axis, Weight, with the tag wght:

You can manage your axes with the gear menu in the lower left corner of the dialog sheet.

Step 2 Set up Masters

In File > Font Info > Masters, add masters with the plus button in the lower left corner of the window, very much like you would for a Multiple Masters project. In our example, we will add two masters, Light and Bold.

For each master, pick the following settings:

1. Make sure you pick an appropriate master name for each master. In our case, I would say Light and Bold are good guesses. The master names are not exported into the final font file. They are important for your own orientation when you work in Glyphs.
2. Most importantly, set the axis coordinates for each master. In our example, set the Weight value, e.g., 50 for the Light Master, and 200 for the Bold Master. Many designers like to use the stem thickness as value for the weight axis value, but you can enter whatever you like, as long as the values are sufficiently different, so that Glyphs can calculate intermediate instances. In our example, we could calculate an instance at numbers between 50 and 200, e.g., 75, 120, 182, etc.
3. Optionally, pick a master icon from the pop-up in the top right of the window. You can select from a range of lowercase n’s representing all sorts of weight and width combinations. You can also enter a glyph name at the bottom, and Glyphs will use an image of the respective glyph as master icon. Again, this is only for your orientation, so pick something that makes sense to you.

Of course, if you scroll down a little in the window, you will find many more settings: zones, stems, custom parameters. You should set them to whatever is appropriate for your design. Just make sure the entered values are compatible. That means that if you add a value in one master, you have to add a corresponding value in all other masters. E.g., if you have some standard stems in one master, the other masters must have the same count and order of stem values as well.

Beta note about axis coordinates: Technically, each axis has a definition of a scale with specific semantics. E.g. the Weight scale must be compatible with usWeightClass to work with CSS and allow switching between fonts while keeping the same relative style. Thus, 400 must be the Regular, and 700 must be the Bold, etc. The Width class must have 100 as the coordinate for the normal width, and the numbers for other masters must be the relative percentage of width vs the normal width, usually 75 for a Condensed, or 125 for an Extended.

Achieving this is a little tricky for the Weight axis in the current implementation. You may either use the spec-defined ranges instead of the stem width, or add Axis Location parameters (see below) to remap the masters. Both options have the downside that the predefined weights between your masters are unlikely to distribute as evenly as usWeightClass assumes. In other words, if you have a Regular master at 400 and an Extrabold master at 800, you are more likely to win the lottery than to have the luck that your Medium instance happens to fit perfectly on 500, the Semibold instance on 600, and the Bold instance at 700.

You could theoretically circumvent this by inserting your instances as masters. This is possible by going to File > Font Info > Instances, selecting one instance after another, and choosing Instance as Master from the Plus button in the bottom left corner of the window, and subsequently switching to the Masters tab of the same window, and resetting their Weight coordinates to usWeightClass numbers. Back in the Instances tab, you can then delete and reinsert the instances with the Add Instance for each Master option, again from that little Plus button.

For now, we recommend to do this only for a seriously shipping font, and not care too much about it while you are experimenting for yourself or for a specific implementation.

Step 3 Draw Compatible Glyphs

To keep it short and simple, we will stick to an uppercase A for this tutorial. I draw the light A with a stemwidth of approximately 50 units, and the bold A with a stem 200 units wide:

Most importantly, keep all your outlines, components and anchors compatible, just as you would in a Multiple Master setup.

Pro tip: You can check compatibility with View > Show Master Compatibility (Ctrl-Opt-Cmd-N), but as long as you do not have any instances defined (see step 4), Glyphs will tolerate outline incompatibility. In File > Font Info > Font, you can add a custom parameter called Enforce Compatibility Check, and Glyphs will connect masters even if there are no instances between them:

Step 4 Add Predefined Instances

Even though our font is variable, and we have an endless amount of instances already, we can still pick some spots in the design space and define them as instances for the font submenu. In File > Font Info > Instances, add as many of those predefined instances as you like. Simply add new instances with the plus button in the lower left, or Option-drag an existing instance entry in the left sidebar to duplicate it.

All you need to do in each instance is this:

1. Set an appropriate Style Name: Light, Regular, Medium, Semibold, Bold, Extrabold in our example.
2. Pick a Weight and Width class from the pop-up menu right below the Style Name. What is important is that the numbers next to the menus are in the right order, because this is how Adobe sorts its font menus. In our example, all fonts have the same Width (Medium/normal, 5), but ascending Weight classes (from Light to Extrabold: 300, 400, 500, 600, 700, 800). For in-between instances, you can also add weightClass and widthClass parameters with in-between numbers. Read more about it in the Naming tutorial.
3. Pick a Style Linking. In the uprights, you leave these usually blank, only the Bold is the Bold of the Regular. And every italic is the Italic of its upright counterpart, e.g., Semibold Italic is the Italic of Semibold. Only the Italic instance is the Italic of Regular, and the Bold Italic is the Bold and Italic of Regular. Read more about it in the Naming tutorial.
4. Pick appropriate design space coordinates for each of your axes. Read more about the distribution of weights in the Multiple Masters, part 3 tutorial.
5. And I hate to break it to you, but many Custom Parameters do not work in an OTVar instance, especially all post-processing ones, like filters. If you have any of those in your instance, they will be blissfully ignored by the software. Why? Because they jeopardize outline compatibility.

Step 5 Export and Test Your Variable Font

Choose File > Export and click on the Variable Fonts tab:

If you have the latest Adobe Illustrator or Adobe Photoshop CC 2108, you can export into the Adobe Fonts folder, choose the font in the Character panel, and open the little slider pop-up to experiment with the Weight axis:

Alternatively, you can drop the font file in one of the amazing web pages that allow you to test fonts. My favorites are Roel Niesken’s great Wakamai Fondue, ABC Dinamo’s Font Gauntlet (which also lets you animate your variable font), and of course Laurence Penney’s Axis Praxis page:

Or, you install the mekkablue scripts and run Test > Variable Font Test HTML, which creates an HTML file next to the latest OTVar export, and opens the enclosing folder in Finder. So all you need to do is drag that into a browser:

Hint: As of this writing, your best guess as browser is the current Chrome or Safari, if you are running macOS High Sierra or later, or iOS 11 or later. Safari will not work on older OS versions. Firefox and Edge should work as well, but make sure you are running the very latest browser version.

If you do want to use a different or older browser, or test on an old OS version, take a look at the Axis Praxis blog: There, Laurence Penney explains where to download and how to set up the pre-release versions of all popular browsers. More and more browsers are adding support for Variable Fonts, or already support them, but you need to enable something somewhere. Laurence explains it all in his post.

Circumventing Bugs

Adobe’s OTVar implementation is buggy. So, if the font does not interpolate properly in Illustrator or Photoshop, it may not be your font’s fault. Symptoms vary, but may include glyphs staying static and not reacting to slider position changes at all, or ugly small kinks appearing during slider movements, e.g., like this:

If that happens, you can try to set different start points in your outlines. We found that this sometimes helps circumvent AI’s rendering bug. In any event, if you see that the same glitch does not appear in the web browsers, it’s not your font’s fault. And it is best to send your font file to Adobe support, alongside an AI file containing a simple test case.

Another annoying implementation bug is sitting deep in Apple’s renderer CoreText. Offsets of components are miscalculated if the LSB is changing. Watch how the a behaves correctly, while the a-umlaut shifts more than it is supposed to do:

This affects all environments that make use of CoreText rendering, which include pretty much all browsers on the Mac. In that case, the best you can do is make sure that all composites are decomposed when you export. Best way to do this: Add a Decompose Components in Variable Font parameter to File > Font Info > Font > Custom Parameters. Needless to say, the resulting TTF will be much larger, and not fit for web use until Apple fixes the issue.

We reported the bug to Apple, but if you have a good case in your hands, please let Apple know as well.

Update: Apple fixed the problem. Make sure you have the latest dot update of macOS 10.13, or a new macOS.

Another bug in Apple’s rendering: The Optical Size axis (opsz) is misinterpreted in Safari. At the minimum (leftmost) slider position, it shows the rendering for the maximum value. This only appears in Safari, not in other browsers. Again, please let Apple know.

Then, there is a rendering problem that is caused by the fact that variable fonts keep their overlaps. Not really a bug, but it may appear to your users as such. If the edge of a shape is drawn by two (partially) overlapping path segments, anti-aliasing will cause the edge to appear darker than the ‘clean’ edges that are drawn only by one outline:

The only solution for this is to rewire your outlines in such a way that the outer edge of your shape is always ‘clean’, i.e., drawn by only one path at any given spot. E.g. like this:

In the very most cases, you will be able to fix this by removing overlaps and subsequently opening corners or reconnecting nodes. Both functions, Open Corner and Reconnect Nodes are available in the context menu of a respective point selection: individual corner nodes for opening corners, and pairs of corner nodes for reconnecting.

If you need these functions a lot, you may want to set a keyboard shortcut. For this very end, we added both to the Paths > Other menu. Set the shortcuts in System Preferences > Keyboard > Shortcuts > App Shortcuts > Glyphs.

Hint: the mekkablue script Paths > Rewire Fire helps you find nodes that need to be reconnected. It cannot find everything, but usually most of the cases that cause unclean edges like the ones shown above. What you want is the option that finds ‘nodes on top of line segments’:

Optional: Add a Virtual Master

Imagine you need an axis which only applies to some glyphs. Let’s say, the crossbar height, which is applicable to letters like A, E, F, H, but not S, D, J, O, etc., and not to any non-letters, like figures, punctuation and symbols. It would not make sense to draw a new master for all the font, would it? Rather, you would introduce an extra master only for those glyphs that have a crossbar. Well, for cases like these, we have something called a Virtual Master:

1. In File > Font Info > Font, add a new axis to the Axes parameter. Since this is not one of the standard axes, names are arbitrary. In this example, I suggest the name Crossbar Height and the four-letter tag CRSB:

2. In the same window tab, add a parameter called Virtual Masters, and give it the value of the the Light master for the Weight axis, 50 in our example, and a minimum value for the Crossbar Height, let’s say zero:

3. Go through all masters in File > Font Info > Masters, and make sure the axis coordinate for Crossbar Height is not zero but, e.g., 100. The idea is that the values make sense semantically somehow. In our case, zero represents the lowest possible crossbar position, and 100 the highest possible position.

Now that the Virtual Master is set up, you can draw the low-crossbar version of each glyph that needs it:

1. Open the glyph in Edit view.
2. In the Layers palette, duplicate the Light layer with the Copy button.
3. Rename the layer copy to {50, 0}, i.e., curly braces containing comma-separated design space coordinates for Weight (50 representing the Light master in our example) and Crossbar Height (0 representing the lowest crossbar position in our example).
4. Now change the drawing to what the letter should look like with Crossbar Height zero:

Note: Unless you want to do some fine-tuning, you will not need to add a Brace layer for the bold master. In Variable Fonts the deltas (point movements) of the two axes compliment each other and can be added up to form the bold with the low crossbar.

That’s it. Now all you need to do is export, and try the font again in Illustrator, Axis Praxis or the Variable Font Test HTML script, et voilà: a second axis is available, for lowering the crossbar towards the baseline:

Effectively, we have added a second dimension to our design space. If you do that, it is advisable to keep the masters in a rectangular arrangement, or even better yet in a vertical or horizontal offset in respect to the origin master. In our example, the Bold master is horizontally offset towards the Light master (difference in the first coordinate only), and the master with the low crossbar is vertically offset (difference in second coordinate only). This way you have the most control because you can reach any point within the design space rectangle by simply adding the vertical and horizontal deltas you created by arranging your masters as described.

Optional: Origin

Only one set of outlines is stored in the font. Non-OTVar-capable software will only be able to display these ‘default outlines’. That default is usually your first master. You can pick a different default, though. To do so, go to File > Font Info > Font and add a custom parameter called Variable Font Origin. As its value, pick the name of a master:

Yes, it must be a master. If you want any of your instances to be the origin, you would need to add the instance as an additional master: In File > Font Info > Instances, select the instance you want to define as your origin, open the Plus button in the lower left corner of the window, and pick Instance as Master from the pop-up menu that comes up. Now you have an additional master in File > Font Info > Masters, and you can set that as your Variable Font Origin.

Two things to consider:

1. Default Appearance: One of the founding ideas behind variable fonts is that you can pick your most used instance as the default, typically the Regular. In Multiple Masters, you designed the extremes of the design space (i.e., your least used instances) and would interpolate everything in between. A variable font can go the opposite direction: it only stores the most important outlines, somewhere in the middle of the design space, and all other instances are derived from that one. So, for desktop fonts, pick the Regular as origin, or whatever the user will expect as the ‘default appearance’ of your font family. If all else fails, this is the weight the user will still be able to use.

2. File Size: Picking a middle master will likely increase the number of your point deltas, and therefore, also increase the eventual file size. On a single-axis setup, it will likely double the number of deltas, if not more. In other words, for webfonts, it makes more sense to pick one of the masters in an extreme end of the design space, because you want to keep file sizes and load times down.

Optional: Axis Location

In File > Font Info > Masters, you can add a parameter called Axis Location. With it you can change the master’s coordinate on the axis. This makes sense if you need different values to be exposed to the users than the interpolation values entered in masters and instances.

In our example, you could argue that a slider going from 50 to 200 may confuse the users of your font. Therefore you want all your sliders to go from 0 to 100, like a percentage. So you will add Axis Location parameters to both masters: Weight 0 for the Light Master, Weight 100 for the Bold Master.

Note: If you add Axis Location parameters, you are effectively changing the axes exported into your variable font. That means you also have to adapt the coordinates of the affected axis in the Virtual Master parameter, if you have one. However, do not change the numbers in Brace and Bracket layers, because those still adhere to the design space created by the original interpolation values.

Limitations

Some things you may have gotten used to, do not work quite as you may expect them to in a variable font.

1. I briefly mentioned above that all post-processing with custom parameters in File > Font Info > Instances is ignored because they are too likely to break outline compatibility or glyph set consistency. That includes filters and the Rename parameters.
2. Corner components work unless they break outline compatibility. But they work differently: in variable fonts, they are applied before interpolation, whereas in a classic Multiple Master setup, they are inserted afterwards.
3. Both Brace and Bracket layers work, but not both within the same glyph. You can have glyphs with Brace layers and other glyphs with Bracket layers in your font, but not a glyph with both Bracket and Brace layers. Sorry about that, we’re working on it.
4. Bracket layers do not translate into composites. There is a script solution for that though. See further below.

Not really optional: STAT Table

In new fonts, including all Variable Fonts, naming info is stored in the STAT table. STAT is short for Style Attributes, and includes, among other things, information about axes, instances, and something called the display strings, or name strings: These are names for sections on an axis. E.g. a weight axis may be sectioned into Light, Regular, Medium, Semibold, Bold; a width axis into Condensed, Regular, Extended.

The idea behind this is that an application can name a user’s current instance, no matter what his or her slider settings are. Effectively, in a multiple-axis setup, you get n-dimensional fields of possible names. E.g., if your font has a weight and a width axis, you get columns of weights, and rows of widths, like in the table below. And in order to name the combination of a weight in the Bold section with a width in the Condensed section, an application can simply combine the display strings, and ta-daaa, we have ‘Bold Condensed’:

A display string is deemed elidable if it is left out when combined with other display strings. Usually this is the case for default-style names like ‘Regular’, ‘Normal’, or the like. The semibold weight combined with regular width is usually just called ‘Semibold’, not ‘Semibold Regular’; or the normal weight in combination with the italic style is simply called ‘Italic’, not ‘Regular Italic’. Thus, the display name ‘Regular’ is considered elidable.

Usually, Glyphs takes care of this pretty smartly by analysing the names of your predefined instances. If however, you find that in the STAT table entries, the display strings are not properly stored in the file, you can take control with these two parameters in File > Font Info > Instances:

• Style Name as STAT entry: Takes the instance style name as combinable display string for an axis range. As value, use the four-letter axis tag to which the display string applies. Use this only in instances that are non-normal on one axis and normal on all others. That is because the normal attributes have elidable names and do not appear in the style name (e.g., ‘Semibold’ or ‘Condensed’). Example: In the Light instance, use this parameter with the value wght, because Light is a value on the weight axis.

• Elidable STAT Axis Value Name: Declares the instance style name as elidable for the axis specified in the parameter value. As value, use the four-letter tag of the respective axis. Typically, you will add this parameter in the regular style, and you will add one for each axis for which the name is an elidable display string. Example: An instance called Regular has two Elidable… parameters, one with wght and one with wdth as parameter values.

Pro tip: The STAT table is becoming increasingly important. In the not-so-distant future, many applications will require one for the font to load in the first place. Don’t ask me where I have picked it up, but let me tell you that if you want to ship (or keep shipping) fonts for Windows, you want to equip all your fonts with STAT. Hint, hint: This will include the Italic (ital) axis for differentiating between Uprights (value 0) and Italics (value 1).

Axis Mappings

One more thing about axes. Obviously, axes start somewhere and end somewhere. In a user interface, the beginning and end of an axis can be (and usually are) represented by the leftmost and rightmost positions on a slider. Everything in between, of course, is spread out evenly between these extremes. In other words, in order to display 25% of the interpolation, you put the slider at the quarter position, for 50% of the interpolation, you put it exactly in the middle, and so on. Makes sense, doesn’t it.

Wait a minute. Does it really? Giving it more thought, it really only makes sense if the instances that the user should be able to access are also spread out (more or less) evenly across the complete slider range. For the sake of the argument, let’s imagine a situation where the important positions are crammed in a small part of the slider range, and a large part of the slider is not doing much for the user.

This actually happens to be the case for the Weight axis (axis tag wght). In (almost all) weight interpolations, the various weight styles are not distributed evenly. Depending how thin the lightest master is and how fat the boldest, you will have more styles grouped together at different ‘focal points’ along the axis. For instance, interpolating from very thin to a ‘normal’, not-too-extreme bold will have styles concentrated towards the light end of the slider:

Why? Because in principle, equidistant movements of the slider correspond to the same changes in units, no matter where on the slider you make the movement. E.g., a certain back-and-forth here changes the design by 10 units, and the same back-and-forth there also changes by 10 units. However, adding 10 units to the stem thickness is a lot for a Hairline, which has only a few units to start with. But the exact same amount is practically negligible for a Medium or Semibold, because in comparison to the stem thickness, it is just a small change.

It is the other way around, if you go from a not-too-extreme Light or Book or Regular on one end towards a very bold Ultra Heavy on the other end of the slider. Now, the styles gather at the bold end of the spectrum:

How is that possible? Well, actually it is the reverse situation to the above, because what changes this time is the white in the letters. For a very, very heavy design, adding or removing 10 units to the white is a lot because there is so little white left. Yet, in the ‘normal’ range of weights between the average Book and Semibold designs, we still have the same situation: the styles are further apart.

Putting one and one together, it is now clear that interpolating from very thin to very bold usually has style concentrations towards both ends of the spectrum:

But on the other hand, the users do not care about our distribution problems, do they? For the users, accessing the different styles works best if they are distributed evenly across the axis, like this:

In other words, we need to somehow translate the evenly distributed user-accessible positions to the appropriately distributed design positions, like this:

This is called an axis mapping. We map what the user sees on the axis, to what the user actually gets on the axis. And we can achieve such a mapping with an Axis Mappings parameter in File > Font Info > Font > Custom Parameters. But how do we set it up? Easy:

1. Determine the extremes on your Weight axis, i.e., the positions of your lightest and boldest masters. For example, we have a project with a Light Master at 50 and a Bold Master at 200.
2. Determine the number of instances across the Weight axis. In our example, let’s say we have six instances: Light, Regular, Medium, Semibold, Bold, Extrabold.
3. Calculate the gap size between styles: divide the difference between extremes by the number of styles minus one. E.g: (200−50)÷(6−1)=30. (Minus one because between six styles, there are five gaps.)
4. Calculate the evenly distributed user-accessible slider positions by starting a the lightest, and repeatedly adding the gap until we hit the boldest. E.g., Light=50, Regular=80, Medium=110, Semibold=140, Bold=170, Extrabold=200.
5. Now add an Axis Mappings parameter in File > Font Info > Font > Custom Parameters and edit its values:

• Choose the Weight axis in the left column, and add six mapping pairs with the plus button, one for each style.
• In the left column, put in the evenly distributed user-accessible slider positions we calculated above.
• In the right column, add the appropriately distributed design positions, or in other words, the actual Weight interpolation values from File > Font Info > Instances.

If you have done everything right, you end up with something like this:

Tip: Make sure you map the extremes to themselves. If you do not have styles positioned at the outermost extremes (in our case, Light at 50 and Extrabold at 200), add mappings there anyway, with the same values in both columns.

You can also switch the parameter to a visual display and fine-tune the axis mapping. Add additional mapping points by clicking on the lines between the dots. Select a dot to edit its coordinates at the bottom: user-accessible number on the left, actual design value on the right. Drag an existing dot up and down to change the design value.

Technically, what this does is create a so-called Axis Variations table a.k.a. avar. It ‘variates’ the axis.

Pro tip: The specification stipulates that the weight axis values should conform to the usWeightClass list of values, i.e. 100=Hairline, 200=Thin, 300=Light, 400=Regular, 500=Medium, 600=Semibold, 700=Bold, 800=Extrabold, 900=Heavy. To achieve that, all you have to do is correlate your master positions to these values, and use those values for the Axis Location parameter in File > Font Info > Masters. In our example, we would add an Axis Location parameter for the Light Master with Weight=300 (because it correlates to the Light instance), and one for the Bold Master with Weight=800 (because it correlates to the Extrabold instance).

Usually, axis mappings will only create subtle changes to the way your font behaves when you drag the slider from one end to the other. So, it will be hard to verify if everything worked out the way you intended it to be. Therefore we need a special tool to inspect the avar table. Luckily, Laurence Penney’s Samsa is such a tool: drag the font onto the page, and in the Axes inspector, turn on the Show avar option:

And then drag the slider to see the green arrow that indicates how the visible slider position (top) maps to the actual design distribution (bottom). You can get geeky extra information if you hover over the visualisation and wait for the tooltip to pop up:

To explain, the avar values go between −1.0, 0.0 and +1.0. Glyphs will usually put your interpolation between 0.0 and +1.0. In other words, in avar, your light master will correspond to 0.0, and your bold master to +1.0. For instance, the tooltip pictured above says that the current slider position 550.4 (at 0.562988... or 56.3%) to the actual design position 540.38 (at 0.550476… or 55%), halfway between Medium (500) and Semibold (600).

Useful scripts

In the mekkablue scripts collection (link includes readme with installation instructions), you will find a number of useful scripts for making your variable font work:

1. Interpolation > Composite Variabler: Reduplicates Bracket layers of components in the composites in which they are used. Makes brace layers work in composites too. E.g., if you have a lowercase g with a brace layer that switches from a double- to a single-storey design as it gets bolder, you need to reduplicate the bracket layer in the composites gcircumflex, gcommaaccent and gbreve. You will still need to decompose the bracket layers after running the script:

Update: Brace layers are not a problem in composites.

2. Kerning > Zero Kerner: Adds group kernings with value zero for pairs that are missing in one master but present in others. Helps preserve interpolatable kerning in OTVar exports. Use this if you find that some kerning goes missing, especially kern pairings that only exist in some masters.

Update: Zero Kerner should not be necessary anymore in Glyphs 2.6.5, builds 1300 and above.

Additional resources

Want to dig deeper and know more about Variable Fonts? We have a few links for you:

• Microsoft: OpenType specification
• Tom Rickner’s background story, ‘From TrueType GX to Variable Fonts’
• Irene Vlachou’s barebones guide to Building variable fonts with Feature Variations
• Roel Niesken’s Wakamai Fondue (‘What can my font do?’)
• ABC Dinamo’s Font Gauntlet
• Laurence Penney’s Axis Praxis
• Laurence Penney’s Samsa for variable font analysis (source code on GitHub)
• Font Drop by the Nübel brothers
• Travis Kochel’s I Can Variable Font, ‘notes on generating variable fonts’
• Andrey Kuzmin’s Font Dimensions, a tool to visualize dimensions of a variable font
• Underware’s fun showcase and proofs-of-concept: Very Able Fonts
• Nick Sherman’s track-keeping of variable font releases: V-Fonts, ‘a simple resource for finding and trying variable fonts’
• Christoph Koeberlin’s variable fonts resource list with many useful links (partially in German, but don’t let that scare you off)

STAT table sample font: Plantago by Viktor Solt-Bittner and Schriftlabor.
Many thanks to Rob McKaughan for his commentary and advice on this tutorial.

Update 2018-03-16: Corrected some typos (thx Jeff Kellem).
Update 2018-06-22: Clarified wording for the example values (thx Karl).
Update 2018-11-20: Updated naming of Variable Font Origin parameter.
Update 2019-02-15: Added links for Font Gauntlet and Wakamai Fondue. Updated test script and browser support info. Added Circumventing Bugs.
Update 2019-03-13: Added Additional resources.
Update 2019-03-04: Corrected typos and replaced Variation Fonts by Variable Fonts of the Export window (thx Nathalie Dumont).
Update 2019-03-20: Corrected typos, replaced Add Instance as Master for Instance as Master, and modified link to Nick Sherman's V-Fonts (thx Nathalie Dumont).
Update 2019-10-23: Added Useful Scripts.
Update 2019-12-04: Added section about the anti-aliasing problem.
Update 2020-03-08: Added paragraph about Safari opsz bug, the hint about the Rewire Fire script, and Samsa to the resources.
Update 2020-06-14: Added Axis Mappings chapter, updated Useful scripts, added a GIF for the Safari opsz bug.
Update 2020-07-09: Minor change of phrase in the paragraph about the Rewire Fire script.

In an all-cap font, the same capital letter should appear whether the user types the key for the lowercase or the uppercase. Read the following easy step-by-step tutorial to make this happen.

A computer differentiates between letters (and thus, also between upper- and lowercase) by means of Unicode values. For example, uppercase K has the Unicode value U+004B while the corresponding lowercase k is represented by U+006B.

A glyph in your font is either accessed by its Unicode value, or, typically the glyphs with a dot suffix, through an OpenType substitution feature, which substitutes a glyph carrying a Unicode value with a glyph that has no Unicode value associated with it. The glyphs with a Unicode value can be typed (that is, if you have the appropriate keyboard layout), or copied and pasted as text.

Double Unicodes

Luckily you can assign not only one, but several Unicode values to a glyph. You can even have Glyphs assign them automatically in one go:

1. In Font View (Cmd-Opt-1), go to the left sidebar and select Categories > Letter > Lowercase.
2. Select all glyphs (Edit > Select All, Cmd-A).
3. Choose Glyph > Remove Glyph (Cmd-Delete). Confirm the dialog that pops up:

4. In the left sidebar, select Categories > Letter > Uppercase.
5. Again, select all glyphs (Edit > Select All, Cmd-A).
6. Choose Glyph > Update Glyph Info.

Now, all Uppercase letters should have two Unicode value assigned: its original uppercase value, plus the corresponding lowercase code. You can verify that everything worked out by selecting an uppercase letter in Font View and looking at its glyph info in the bottom left:

See, where it says Unicode, it shows more than one entry. High five!

Dilemma of the Dotted i

The relationship between uppercase and lowercase is not the same for all languages though. Turk languages, including Turkish, Azeri and Tartar, relate the lowercase (dotless) ı to the uppercase (dotless) I, and the lowercase (dotted) i to the uppercase (dotted) İ, whereas non-Turk languages, including French, English, Spanish and German, relate the lowercase (dotted) i to the uppercase (dotless) I.

The logical problem is now: Which uppercase glyph should receive the Unicode value for the lowercase (dotted) i? If your answer is I, then your font is incompatible with Turk languages. If it is Idotaccent, it is incompatible with all non-Turk languages using the Latin script. A dilemma.

But fear not, there is a viable workaround. In order to support both Turk and non-Turk languages (at least in OpenType- and language-aware applications like Adobe apps), we need to keep the following three lowercase i glyphs around: i, idotless and idotaccent. Choose Glyph > Add Glyphs… (Cmd-Shift-G) and past this recipe in the dialog that follows:

I=i
I=idotless
Idotaccent=idotaccent

In other words, in an all-caps font, i and idotless should be an uppercase I without a dot, and idotaccent an uppercase İ with a dot. Like this:

Then proceed to File > Font Info > Features, and click the Update button, so Glyphs can insert a locl feature that swaps i with idotaccent if the language is set to Turkish, Azeri, Crimean Tartar, etc. And the proper relationships between lowercase and uppercase are preserved.

Features and Glyph Set

Do not forget to update the automatic and manual OpenType features in File > Font Info > Features (Cmd-I). And consider removing some features that may not make sense anymore when there are no lowercase letters, like the case and cpsp feature.

You may also rethink your glyph set. An all-caps font usually will not need old-style figures, and the lining figures will probably not need any height compensation and can stretch to the full cap height. You may also want to reconsider the design of your parentheses, brackets and curly braces. Your quotes, dashes, bars and slashes will only need to match the caps.

Metrics

If you are converting a font from mixed case to caps-only, and you had a cpsp feature for increasing the tracking between the caps, you may want to incorporate the extra spacing into the sidebearings of the uppercase glyphs containing paths. If you are employing auto-alignment in your compound glyphs, they will follow automatically. To do so, follow these steps:

1. In Font View (Cmd-Opt-1), open the gear menu in the lower left corner and choose Add Smart Filter.
2. In the Smart Filter options, pick an appropriate name, then add the conditions Count of Paths: is greater than 0 and Category: is Letter, and confirm by pressing OK.
3. Make sure the smart filter is selected, and select all glyphs displayed by the filter (Cmd-A).
4. In Filter > Transformations > Metrics, select the Relative option, and add your cpsp increment (typically a value like 5 or 10 units) to the glyphs. Confirm with OK.

Now all your remaining uppercase letters have the sidebearings they need.

Vertical Metrics

In File > Font Info > Masters (Cmd-I), you can probably get rid of the Alignment Zones for x-height, ascender and descender. Your Standard Stems only need to match the uppercase stems.

Do keep the Ascender and Descender values around, though, since they will be used to derive the vertical metric values written into the respective OpenType font tables OS/2 and hhea (see the Vertical Metrics tutorial for details). It is best to keep these values around the font master’s highest and lowest bounding box values, typically found in diacritics like Ccedilla and Ohungarumlaut.

Problems with Double Encodings

As much as double encodings can cut down on file size, there is also one problem with certain PDF workflows. Copying selected text from a PDF can result in garbled casing of the character stream inside the clipboard, i.e., coPiED tExt caN END uP looKiNg liKE tHiS, unless the PDF was created in a certain way (hint: not with Acrobat Distiller) and the text extraction is also done in a certain way. Don’t worry, this just affects the text in the clipboard, the representation in the PDF will be fine. Then again, text extraction from PDF is flawed anyway, and if this is not much of a concern for you, you’re good.

Otherwise, your only option is to actually duplicate the glyphs, which best is done with a single-component recipe through Glyph > Add Glyphs… creating component copies of your uppercase letters, as described in the tutorial about recipes.

Update 2018-04-24: Added Problems section. Thanks to Aaron Bell, Khaled Hosny, and John Hudson.
Update 2018-06-29: Added Dilemma of the Dotted i section. Thanks to Mark Richardson (@superfried).
Update 2018-02-21: Corrected typos.
Update 2020-09-22: Updated for Glyphs 3.

In an all-cap font, the same capital letter should appear whether the user types the key for the lowercase or the uppercase. Read the following easy step-by-step tutorial to make this happen with Glyphs Mini.

A computer differentiates between letters (and thus, also between upper- and lowercase) by means of Unicode values. For example, uppercase K has the Unicode value U+004B while the corresponding lowercase k is represented by U+006B.

In case you were wondering what the U+ means: it is the marker for a Unicode hexadecimal code. The most important codes, the codes in the so-called ‘Basic Multilingual Plane’ (BMP) have four digits and can be represented with 4 hexadecimal digits, from U+0000 to U+FFFF, in total 65,536 code points, containing the characters for all modern writing systems. Read more in the Unicode tutorial.

A glyph in your font is either accessed by its Unicode value, or, typically the glyphs with a dot suffix, through an OpenType substitution feature, which substitutes a glyph carrying a Unicode value with a glyph that has no Unicode value associated with it. The glyphs with a Unicode value can often be typed (that is, if you have the appropriate keyboard layout), or copied and pasted as text.

Double Unicodes

Luckily, since Glyphs Mini 2.0.2 (91), you can assign not only one, but several Unicode values to a glyph. You can even have Glyphs assign them automatically in one go:

1. In Font View (Cmd-Opt-1), go to the left sidebar and select Categories > Letter > Lowercase.
2. Select all glyphs (Edit > Select All, Cmd-A).
3. Click the minus button in the lower left corner in order to remove the glyphs. A confirmation dialog will pop up:

Now, when you export, all uppercase letters that do not have a corresponding lowercase letter, should also get the lowercase Unicode value assigned on export. The change is not reflected in the user interface, but you can test your font with the Adobe Fonts folder or into a separate folder and test your font with TextPreview.

Dilemma of the Dotted i

The relationship between uppercase and lowercase is not the same for all languages though. Turk languages, including Turkish, Azeri and Tartar, relate the lowercase (dotless) ı to the uppercase (dotless) I, and the lowercase (dotted) i to the uppercase (dotted) İ, whereas non-Turk languages, including French, English, Spanish and German, relate the lowercase (dotted) i to the uppercase (dotless) I.

The logical problem is now: Which uppercase glyph should receive the Unicode value for the lowercase (dotted) i? If your answer is I, then your font is incompatible with Turk languages. If it is Idotaccent, it is incompatible with all non-Turk languages using the Latin script. A dilemma.

But fear not, there is a viable workaround. In order to support both Turk and non-Turk languages (at least in OpenType- and language-aware applications like Adobe apps), we need to keep these three lowercase glyphs around:

i
idotless
idotaccent

Design i and idotless as an uppercase I without a dot, and idotaccent as an uppercase I with a dot.

Then Glyphs Mini can insert an OpenType feature that swaps i with idotaccent if the language is set to Turkish, Azeri, Crimean Tartar, etc. And the proper relationships between lowercase and uppercase are preserved.

Vertical Metrics

In File > Font Info… (Cmd-I), you can probably get rid of the Alignment Zones for x-height, ascender and descender. Your Standard Stems only need to match the uppercase stems.

Do keep the Ascender and Descender values around, though, since they will be used to derive the vertical metric values written into the respective OpenType font tables OS/2 and hhea (see the Vertical Metrics tutorial for details). It is best to keep these values around the font master’s highest and lowest bounding box values, typically found in diacritics like Ccedilla and Ohungarumlaut.

Problems with Double Encodings

As much as double encodings can cut down on file size, there is also one problem with certain PDF workflows. Copying selected text from a PDF can result in garbled casing of the character stream inside the clipboard, i.e., coPiED tExt caN END uP looKiNg liKE tHiS, unless the PDF was created in a certain way (hint: not with Acrobat Distiller) and the text extraction is also done in a certain way. Don’t worry, this just affects the text in the clipboard, the representation in the PDF will be fine. Then again, text extraction from PDF is flawed anyway, and if this is not much of a concern for you, you’re good.

Update 2018-04-24: Added Problems section. Thanks to Aaron Bell, Khaled Hosny, and John Hudson.
Update 2018-06-29: Added Dilemma of the Dotted i section. Thanks to Mark Richardson (@superfried).
Update 2020-11-13: Updated for Glyphs 3 website.