Last week I wrote about posting five FontLab encoding files for Adobe Latin character sets.
Today I posted in the same Github repository three FontLab encoding files for Adobe Cyrillic character sets, and updated the five Latin files with a few added currency symbols and glyph name changes (as I expected I might).
The character set definitions underlying these files were built on a bunch of research I did at Adobe back in 2006–08, with additional work by Miguel Sousa. The headers include much detail on the differences between each set, and the languages covered. Both of these character sets reflect the latest data from Adobe on how they name glyphs and what they are including in current fonts (not including OpenType alternates and features, mind you). The headers of the files have some interesting details and history, especially on the Cyrillic side.
Thanks as always to my old friends at Adobe, including Miguel and David Lemon, for their willingness to share production information with the type design community.
I dedicate this post and my work on the Cyrillic encoding files to the memory of Emil Yakupov, CEO of the ParaType type foundry in Moscow, who passed away just a month ago at the age of 56. His advice and feedback on Cyrillic character sets—among many things—was invaluable to me. I remember one of our first meetings, when Emil gave me a pair of ParaType catalogs as I was first becoming involved with Cyrillic type design. I still consult them to this day when trying to internalize what forms different Cyrillic characters can take in different font styles.
Also, Emil remembered by Adam Twardoch.
I just posted some free FontLab “.enc” encoding/character set files for the five Adobe Latin character sets, in my Github repository.
To install, quit FontLab, find the “Encoding” folder in the shared “FontLab” folder, and drop the files in there. Restart FontLab and these will be available as encodings.
NOTE: These were later updated to reflect minor tweaks Adobe has made since I described the character sets and posted the data, almost six years ago. I added currency symbols such as the Indian rupee, Turkish lira, Russian ruble and Ukrainian hryvni, and changed a few glyph names to match current Adobe practice. Thanks as always to my old friends at Adobe, including Miguel and David Lemon, for their willingness to share production information with the type design community.
This follows a couple of possibly-useful FontLab scripts I posted a couple of weeks ago, in the same place.
I have started posting a few scripts in my own repository on GitHub. They are libre (free, open source) under an Apache 2.0 license.
- Generate-substitutions.py: Select some glyphs in the font window. Run the script. It will automatically generate useful OpenType feature code (in .fea/AFDKO syntax) in the Output window, which you can copy/paste right into the appropriate feature. The script works with both simple substitutions and ligatures as long as you follow standard Adobe glyph naming standards (appropriate use of period and underscore). It does not work with complex cases involving multiple-feature interaction, sorry.
- Make-numbers-from-dnom.py: First you need to create some numbers sized and positioned for use as denominators. The script will take all the glyphs in your font ending in “.dnom” and create numerator, superscript and subscript versions using the dnom glyphs as components. If the font is an italic font, it will use the italic angle of the font to calculate how much to shift the components horizontally while moving them vertically. NOTE: the vertical shifts are hardcoded in the script now, but easily edited. Future improvement ideas: pop up a dialog to enter the vertical shift numbers, and/or try to auto-calculate them.
Unfortunately, my “best” (or at least most complicated) script is very specific to my workflow on developing my Cristoforo family (it does the steps detailed at the bottom of this blog post). It is a heavily modified version of Ben Kiel’s “Better Generate Font” script. I chose not to post it as the workflow is just so very peculiar to my needs and does things like put my license URLs in the font, but if you want it for some reason, perhaps as a starting point, ping me.
I am very excited to be getting my visa for India today! I’m one of the instructors for a 3-day advanced type design workshop with FontLab. Registration is now open on the FontLab blog, and there is a detailed schedule of planned talks.
Adobe has just released a new version of the Font Development Kit for OpenType (AFDKO). This is an important milestone for font developers.
Even if you don’t use it yourself, the AFDKO code is licensed at no cost to developers of other font tools such as FontLab and DTL FontMaster. It forms the basis of the OpenType generation and OpenType features support in those tools. So very often new functionality in the AFDKO is a preview of new functionality in these other tools, and hence indirectly of capabilities of both Adobe and other vendors’ fonts. It’s reasonable to suspect that features in the AFDKO will preview new features in future versions of FontLab Studio (maybe 6.0?) and DTL FontMaster (look at the DataMaster tool in particular).
So, with the new FDK, and one hopes in future versions of FontLab Studio and DTL FontMaster, users are able to build fonts which support complex scripts (Arabic, Indic, etc.), without using Microsoft’s VOLT as a separate process. All (yes all) OpenType GSUB and GPOS lookup types are supported. There’s support for Unicode Variation Sequences, especially useful for Japanese and ideographic languages. Plus one can give “friendly” names to stylistic sets, although this last will also need to be supported by applications, and I wouldn’t hold my breath waiting for that. Plus there are various bug fixes and lesser features.
What is the AFDKO, exactly?
The AFDKO is a set of command-line (yes, really) font development tools available for Mac, Windows and Unix. They cover compiling, proofing, testing and some editing of OpenType fonts. Compiling a font requires a basic TrueType, Type 1 or OpenType font as input; what the AFDKO does is add OpenType layout features to an existing font (as in, you still need a font editor).
I’m particularly fond of the “CompareFamily” tool, which is unusual in that it not only does tests on individual fonts, but looks at how information and key values are coodinated across a family. This is very useful for checking things such as style linking, or making sure your trademark statement is identical in all members of the family.
Because this stuff is command-line driven, it may not be for the average user. Besides which, many folks may prefer to use functionality which is integrated with their font editing environment. But for those who need reliability and a controlled, repeatable build process, the FDK is a nice option to have.