By roundtripping through Area51.
- Floats that want to be ints become ints
- Widthname 'normal' normalised to a field value from the
Opentype OS/2 table usWeightClass 'Medium (Normal)'
- Placeholders for PostScript hinting data
For accented glyphs as acute.glif there exist alternative versions
The versions without the suffix are the ones mapped to a unicode point, and
the ones actually used by applications. The alternative versions differ in
their exact placement of the accent.
Since having multiple variants is confusing, I’m deleting them. If you want,
you could look at these glyphs in the history and see if their accent
positions look better than those in the standard glyphs. If so, you can copy
over the coordinates to the standard glyphs.
Now you can compile a font! Works with both FontForge and the Adobe Font
Development Kit for OpenType. The former is what we aim for as our main
compiler, as the latter is closed-source, but to have both is great for
testing the UFO spec.
Run ''rake'' to generate the font. ''rake diagnostics'' will give you an
overview of your current build environment and advise you how to proceed if it
can’t find the right build tools.
If you want more control you can use tools/ufo2otf.py which provides a command
line interface: you can choose input and output files, and which compiler to
Or rather, any otf file found in the folder. I had to remove generating
OpenBaskerville.otf as a dependency, since it can conflict with the upcoming
'generate release' task. I should probably look into rake namespacing.
In the metadata, removed entries related to FOND resources, I am not sure if
they are actually useful, and they could cause conflicts when installing
multiple Open Baskervilles.
When a designer uses a font, it is critical that she or he can identify the
particular version unambigously. We also want to make sure that designers can
use our development snapshots. That’s why for every commit there needs to be a
potential version number. We could, theoretically, use git hashes as
identifiers. However, they look cryptic to end users, and they don’t provide
information about the chronology of versions.
Taking cues from the semver.org spec, our version number takes a form X.Y.Z.,
where X is the major version, Y the minor version, and Z the patch version.
Minor versions have a defined set of goals, and get tagged in Git, we started
with 0.0.0 and we are now working towards 0.1.0.
Our patch versions, are built from the source tree after each commit. So from
the first commit after 0.1.0 we can build 0.1.1.
To do a release, we use the ''git describe'' command to tell us the last tag
and the number of commits since that tag, whereupon we base a version number
that we bake into the ufo and thus into the generated font.