fontmake v/s afdko

kedar

Hi,

I am in process of making (and publishing) my first font.

As I research the publishing guidelines and standards, I found that the two font generating and building tools that are most widely used are: fontmake and afdko.

But, I am trying to understand is if they are just two tools who get the same thing done (like GlyphsApp and FontForge) or are they two different steps in the professional font development process?

I apologize if this is an elementary question for some but, there is really very less resources online about the process of building and generating fonts for professional usage.

I would also appreciate if someone has a documentation on this process. 

Thank you 🙏

Thomas Phinney

Mostly, they are two tools for the same thing(s).

At least some bits of AFDKO are built into a lot of other tools, by the way, including GlyphsApp.

kedar

Thanks @Thomas Phinney

Georg Seifert

Glyphs 3 doesn't contain makeOTF any more.

Thomas Phinney

Interesting! Are you using your own code, FontMake, or something else?

Georg Seifert

Our own code.

Adam Twardoch

AFDKO is an older set of tools and libraries that was created to convert between various font formats. Its most-used components were those for converting Type 1 fonts into CFF-based OpenType fonts, for compressing the CFF table using subroutines, and to compile feature definitions from the FEA format into binary OT tables. AFDKO is mostly written in C/C++, with some code in Python. 

fontmake is a small tool that uses a large set of libraries written in Python, written from scratch or significantly extended in the last few years. Its core is fontTools, originally a Python-based OpenType parser, today a set of libraries that provides alternative, newer implementions of most of the commonly-useed AFDKO modules. There are additional libraries like ufo2ft or glyphsLib that fontmake uses to convert other formats into something fontTools can compile. 

Originally, developers used AFDKO and fontTools in combination. In fact AFDKO does use fontTools itself in small bits. The code of ADFKO was a haphazard mix of different languages and programming styles and glue-code. 

fontmake, fontTools and the other libs are written in a much cleaner way, esp. since the migration to Python 3. Almost all of relevance what AFDKO could do the fontTools-based workflow can do (I find calling it "fontmake" is a bit of misnomer, fontmake really is just a small frontend). 

Users still use AFDKO because it's well-established and it's shortcomings are well-known. But the community is gradually migrating towards the Python-only ecosystem built around fontTools and fronted by fontmake. 

Adam Twardoch

AFDKO and fontTools is an interesting case if you compare how they came to be. Both projects are opensource, but there is an important difference. 

AFDKO was developed in-house within Adobe, to fit Adobe’s own workflows for font development, and also their particular focus on the types of fonts they were making. Adobe made the source of AFDKO available to interested parties so that apps like FontLab could bundle the compiled code.

Overall, the number of people who had insight into the code was small. Because there were hardly any open collab tools for code, changes and fixes, even if made by some of those who had insight, may have only ended up in the private forks.

Much later, Adobe opensourced the bulk of AFDKO. This was great — but the code remained very tied to its original limitations: there are many functionalities for Euro-centric fonts but few for complex scripts.

fontTools was different. It was opensource from day one. When Behdad Esfahbod and Google i18n took over its maintenance, and the code appeared on Github, a large group of people could advance it.

People added new functionalities and other libraries quickly, and they all worked well together. The ecosystem around fontTools outgrew the original scope of the library many times.

I think the fontTools ecosystem is better, largely because the library was opensource from the start, so it could grow by consensus.

AFDKO was an in-house package for a long time. It’s fine, it’s great that it’s there, but it didn’t enjoy the benefit of “many eyes” for that long. 

kedar

Thanks @Adam Twardoch
That was very insightful.