The proposed changes, taken as a whole, allow us to create compact pan-Unicode fonts made up of reusable parts that are built using enhanced variation capabilities. Further, the designer is empowered to separate how the parts are crafted and assembled from how they are presented to the user.
The input to a font is often from a design tool that uses cubic curves. Quadratic approximation reduces quality and increases filesize. Explicit support for cubic curves in
glyf resolves both
Design tool features like smart components allow designers to build fonts out of reusable parts. For CJK we've seen experiments where tens of thousands of glyphs are built from at least an order of magnitude fewer parts.
By enabling reuse of a glyph at a different position in designspace the font binary can leverage this to significantly reduce filesize. See prior art in Variable Components for COLRv1.
This can be done by leveraging
COLR or by enhancing
Reduce complexity in the design of variable fonts and produce more compact files.
User-facing axes (weight, width, etc) are currently the same axes the designer uses. However, these axes are not naturally orthogonal. Designers are forced to resolve this by introducing additional masters, which costs the designer time and the end user bytes. A better system would enable user-facing axes to be assembled from other axes, which could (and should) be orthogonal.
The Type Network axis set is a relatively well known example.
To assemble a set of non-orthogonal user facing axes from a set of orthogonal axes requires a
non-linear many:many mapping.
avar provides a piecewise linear mapping from an input position
on a single axes to a different position on that axes. This is inadequate; a new and more powerful
mapping mechanism is required.
It's clear non-linear interpolation (NLI) is desired and, perhaps unintentionally, possible due to being able to provide multiple scalars which are multiplied together. See NLI in Variable Fonts.
Today NLI is complex and not necessarily size-efficient. Add additional basis functions to support NLI, clean mapping of an axis value to rotation, and extrapolation.
If, as proposed, we add variation aware components and stronger mapping between user-facing and internal axes it becomes increasingly desirable to have larger numbers of axes, each performing a narrow task. Currently use of an axis comes with a huge penalty: variation stores encode positions for all axes rather than only the axes that contribute to the result.
Upgrade the variation stores to only consume bytes for axes that influence the result.
HarfBuzz text shaping engine
An opinionated HarfBuzz Python binding
ICU Layout Engine API on top of HarfBuzz shaping library
HarfBuzz tutorial; will probably be merged with HarfBuzz repo soon
Python module to access all of Unicode Character Database
Test data for HarfBuzz text shaping engine, extracted from Wikipedia