-
Notifications
You must be signed in to change notification settings - Fork 10
Add first draft #23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add first draft #23
Conversation
|
Thanks Nikolaus! I am working on a draft locally. I will merge this into my branch and add my edits on top. |
|
Pushed what I currently have to the remote. More to come. Thanks again Nikolaus! |
|
|
||
| ### Current Tools | ||
|
|
||
| fontmake. It's the glue that binds together ufo2ft, fontTools and some other codebases to take any of the usual font formats (UFOs, Designspace + UFOs and Glyphs.app files) and produce font binaries (TTF, CFF(2); static, interpolated static, variable). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nanoemoji, though limited in scope, may bear mention. Significant primarily because it uses python to write ninja and that has proven to be very effective for those parts of the process that are readily amenable to ninja.
A section on low hanging fruit, such as introducing parallelism to fontmake, would be interesting.
An interesting decision is coming: should we try to speed up fontmake before, or instead of, waiting on a new compiler.
|
|
||
| ### Key Limitations | ||
|
|
||
| * Python is bad at embarrasingly parallel tasks like instance generation and glyph compilation due to overhead and lacking multicore facilities. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
even if we imagine a ninja'fied fontmake?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'd typically ninja complete build steps, generating glyf and gvar is probably impractical due to granularity and overhead. Instance generation, maybe, depending on the project. I think googlefonts/gftools#569 implements something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instance generation works fine, which is (partly) what I'm doing with gftools.builder.ninja. A gftools-builder run (which is intended to bring an entire family to production) is a much larger superset of operations than a fontmake run:
- It typically runs on more than one source file at once (i.e. Upright and Italic sources for a family)
- It typically builds a wide variety of output fonts (variable TTF, TTF, OTF)
- There are typically other steps that you want to orchestrate in a
make-like context (autohinting each TTF output, converting each TTF to a webfont, running hotfix scripts, converting each TTF output to building STAT tables when all output variable TTFs are complete)
So that gains a lot from using ninja. I get roughly a 3x speedup.
It is possible to break up some of the operations that fontmake does and use ninja to orchestrate them, in some contexts. Generally this is when you are dealing with static instances (-i flag):
- Creating instance UFOs from a Designspace file is currently done in serial, can be done in parallel.
- Creating instance binaries from each instance UFO is current done in serial, can be done in parallel.
- Creating master binaries from each master UFO is current done in serial, can be done in parallel.
On the other hand, building a single variable font would only involve the last of these operations, and I'm not convinced that's enough of a gain to warrant the work of adding ninja orchestration.
Just so you see the degree of separable operations in a gftools-builder run, here is a ninja -t graph dump of gftools.builder.ninja for a typical font family:
| * It's easy to run into performance problems with OpenType Layout table repacking, which quickly consumes a large part of the compile time. | ||
| * Codebases have grown organically by adding new things on top, some parts are byzantine and hard to change, making optimizations or rearranging code paths hard. | ||
| * VF generation requires compiling all masters fully and then merging them, instead of generating variable data directly. | ||
| * fontmake is underloved from a maintenance perspective, with some low hanging performance fruits continuing to hang. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is true. The last time we had this discussion (fonttools/fonttools#1095) we concluded there weren't many low-hanging fruit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, maybe I should have written instead "it still keeps writing out intermediate UFOs even when not requested" which holds up the process.

No description provided.