VIDEO HERE

(ALSO 2021 EDITION)

Better-Engineered Font-Formats

an update�

ATypI 2023—Paris

behdad & others

What’s in a name?

​

engineered

adjective

• 1. (of an organism) modified by manipulation of genetic material.�"genetically engineered plants"
• ​
• 2. skillfully and deliberately arranged rather than arising naturally or spontaneously.�"they plan to spy on Hamlet at a future, engineered meeting with Ophelia"

​

3

Part 1: Boring Expansion

​

Part 2: Better Ergonomics

​

Part 3: Beyond Emulation

Discussion

Discussion

5

6

Part 1 of 3:�Boring  E x p a n s i o n

Business as usual

Boring Expansion: What’s in a name?

bor·ing

adjective

• not interesting; tedious.

​

bore

verb

make (a hole) in something, especially with a revolving tool.

8

Boring Expansion: What is it?

Extend the font format:

• To address decades-long limitations.
• Add highly-desirable features.
• Maintain general design structure, such that:
• Fonts not using the new features are generally backward compatible with the existing format.
• It’s okay if adoption takes time. Many of these ideas were suggested back in 2015… If we had acted on them then, we could use them today. We have to act now, so we can rely on them in 5 / 10 years. That is just how format changes work.

9

Boring Expansion: So far…

• avar2�https://github.com/harfbuzz/boring-expansion-spec/blob/main/avar2.md�
• Cubic glyf outlines�https://github.com/harfbuzz/boring-expansion-spec/blob/main/glyf1-cubicOutlines.md�
• VarComposites�https://github.com/harfbuzz/boring-expansion-spec/blob/main/glyf1-varComposites.md�
• beyond-64k�https://github.com/harfbuzz/boring-expansion-spec/blob/main/beyond-64k.md

​

10

avar2: What is it?

• New version of the avar table that supports arbitrary mapping across variation axes.

​

• Specification:�github.com/harfbuzz/boring-expansion-spec/blob/main/avar2.md

​

• Support: FontTools, HarfBuzz, FreeType, macOS/iOS

11

avar2: Use cases

• Designspace warping
• Higher-order interpolation (HOI, aka Non Linear Interpolation)
• Parametric fonts
• Designspace fences

12

avar2: How it works

• In avar1, each axis can be remapped individually �and piecewise linearly.�
• In avar2, each axis can be remapped as a function of all input axes. �This allows saving corner masters in many designs.�
• “Mom, You Sure Can Re-hydrate a Pizza (or: avar table version 2.0)”�docs.google.com/presentation/d/1jLiUvh4PoYz2sw0T0Fygj2HoMrBhmJQuGgAmoMc_Sns�youtu.be/j7unMVZOcaw

13

avar1: Old model

Adjustments limited to one axis at a time.

14

Input:

​

Weight

Width

Optical Size

Grade

​

​

Output:��Weight�Width�Optical Size�Grade���

avar2: Designspace warping

Adjustments across axes.

Input: Output:

15

Weight

Width

Optical Size

Grade

​

Stem width�True width�Contrast�

avar2: Higher-order interpolation (aka HOI)

No user-visible hacks needed for higher-order interpolation.

Input: Output:

16

Weight

�Weight1�Weight2�

avar2: Parametric fonts

Vastly fewer corner masters needed in parametrically-designed fonts.

Input: Output:

17

Weight

Width

Optical Size

Grade

​

XOPQ�XTRA�YOPQ�YTLC�YTUC�YTAS�YTDE�YTFI

avar2: Designspace fences

Make undesirable regions inaccessible.

18

Deberny & Peignot, 1964

avar2: Results

• Prototypes: Parametric fonts:
• 80% file-size savings in Roboto Flex
• 70% file-size savings in Amstelvar

19

Cubic glyf outlines: What is it?

• Extension to the glyf table to support cubic Bezier curves.

​

• Specification:�github.com/harfbuzz/boring-expansion-spec/blob/main/glyf1-cubicOutlines.md

​

• Experimental support: FontTools, HarfBuzz�Patch: FreeType

20

Cubic glyf outlines: Use cases

• Higher-fidelity representation of outlines, especially important for:
• lower units-per-EM fonts,
• very light weights,
• variable fonts with many interacting masters, as conversion errors accumulate.

​

• Slightly smaller fonts.

21

Cubic glyf outlines: How it works

• New flag in the SimpleGlyph outline specification to imply cubic Bezier off-curve points.

​

• Implied on-curve points between two cubic segments supported.

​

• Hinting capability unaffected.

22

Cubic glyf outlines: Results

• Roughly 3% to 10% savings by just rebuilding fonts from existing sources, depending on how curve-heavy the design is.

23

VarComposites: What is it?

• Extension to glyf table to support variable components, aka “smart components”.

​

• Specification:�github.com/harfbuzz/boring-expansion-spec/blob/main/glyf1-varComposites.md

​

• Experimental support: FontTools, HarfBuzz

​

• Based on proposal by Black Foundry / Just van Rossum.

24

Classic components

• References another glyph at the font’s current variations settings�
• Translation offset: variable�
• 2x2 transformation matrix for scale, rotate and shear: not variable!

25

Variable components

• References another glyph an arbitrary variable location in the variation space�
• Translation offset: variable
• Rotation: variable
• Scale: variable
• Shear: variable
• Center of transformation: variable

26

VarComposites: Use cases

• Han fonts
• Hangul fonts
• Tibetan fonts
• Latin stencil / modular fonts
• Icon fonts
• …

27

VarComposites: How it works

• Each VarComposite glyph refers to components at certain �location in the component glyphs’ designspace.

​

• Same component can be used to provide a variety of shapes.

28

VarComposites: Results

• Han varfont with 2 weights & ~44k ideographs:�

63% file-size savings

​

• Hangul varfont with 2 weights & ~11k syllables:�

72% file-size savings

29

beyond-64k: What is it?

• Extension to the font format to support more than �the current glyph limit: 65,535!

​

• Specification:�github.com/harfbuzz/boring-expansion-spec/blob/main/beyond-64k.md

​

• Experimental support: HarfBuzz�Proof-of-concept: FontTools, FreeType

30

beyond-64k: Use cases

• Massive CJK fonts

Currently Noto CJK / Source Han CJK fonts at maximum glyph count, and missing many CJK characters.

• Pan-Unicode fonts

Currently pan-Unicode fonts use 100+ separate files that are hard to organize / order, with distinct family names. This feature allows eg. having one NotoSans.ttf as One Font to Rule Them All.��Simplifies document fallback where file-size is not constrained, or incremental transfer is available

31

beyond-64k: How it works

• 24-bit glyph indices instead of 16-bit, allowing 16m glyphs.�Ought to be enough for everyone, right?��For context, Unicode allows up to ~1m codepoints, �of which currently ~150k are used.
• Noto fonts use less than 200k glyphs total (due to many scripts’ conjuncts)

​

• Many tables updated to allow more than 64k glyphs.

​

• Most intensive changes applied to the GDEF / GSUB / GPOS tables, also alleviating the long-standing offset-overflow issues. Designed for code-reuse via templates.

32

beyond-64k: Results

• 15MB merged NotoSans.ttf, containing all scripts except for CJK.
• Over 100,000 glyphs.
• GPOS table over 1.5MB, compiled successfully without overflows.

​

• Drawback: HarfBuzz binary size growth +100kb (+%10)

​

33

Boring Expansion: Future work

• Next-gen Variations:

Native support for higher-order interpolation? More compact storage?

​

• Next-gen Layout:

Address long-standing issues in OpenType Layout: a move lookup, arbitrary glyph filtering, a more compact / powerful contextual lookup…

​

• Streamline / relax the spec where possible, deprecate old cruft.�
• Specification of variable justification

34

Variable justification: What is it?

• Use the jstf variable axis tag for text justification.

35

Variable justification: Use cases

• Arabic kashida and other stretching
• PdfTeX-like “micro-typography”

36

Variable justification: How it works

• Font defines the jstf variable axis tag.
• Various justification priorities all baked into the one axis.
• Typesetting engine finds the right variable axis setting that fits the line.

​

TODO:

• Figure out solution for glyph substitutions, as current FeatureVariations-based solution is inadequate.

37

Variable justification: Results

38

Part 2 of 3:�Better Ergonomics

The one where we rebuild everything

Better Ergonomics: What’s in a name?

​

er·go·nom·ics

noun

• the study of people's efficiency in their working environment.

​

41

Better Ergonomics: A tangent

• Rewrite everything in Rust (from Python/C/C++):
• No more security vulnerabilities, yay!
• Super-fast fontmake-rs font compiler.

​

• Produced a new font Internal Representation (IR).

​

• Can inform new font source format and future font binary format, if any.

​

• github.com/googlefonts/oxidize

42

43

Part 3 of 3:�Beyond Emulation

Putting the smart into fonts

Beyond Emulation: What’s in a name?

​

em·u·la·tion

noun

• effort to match or surpass a person or achievement, typically by imitation.�"their success is inspiring emulation from others"
• ​
• COMPUTING�reproduction of the function or action of a different computer, software system, etc.�"software emulation of complete systems"

​

45

Beyond Emulation: Problem statement

46

OpenType shaping

Beyond Emulation: Problem statement

• Complex scripts bump up against the limits of OpenType Layout
• When you need to calculate things
• “Flow fonts”, connected shorthand, etc.
• When you don’t know how many things you have until run-time
• sub @flagged @any @any @any @any @any @any @any @any @above;�sub @flagged @any @any @any @any @any @any @any @above;�...
• When you don’t know what things you have until run-time
• When you don’t know where things are until run-time
• Egyptian hieroglyphs
• Arabic dot collision avoidance
• Automated kerning

47

Graphite & Nastaliq

Sharon Correll

Beyond Emulation: What is it?

• WebAssembly for President!�
• Optionally embed font shaping logic in the font’s Wasm table.�
• Interpreted by the shaping engine in a secure environment.�
• Puts the font engineer in the driver’s seat.�
• https://github.com/harfbuzz/harfbuzz/pull/4131�https://github.com/harfbuzz/harfbuzz/blob/wasm/src/hb-wasm-api.h

​

49

Beyond Emulation: Use cases

• Graphite, DecoType ACE, other alternate shaping engines
• Custom programmatic shaping (collision avoidance, etc)
• Custom effects

50

Beyond Emulation: How it works

51

Beyond Emulation: Demos

• SIL Graphite2
• Arabic collision-avoidance / kerning
• Arabic baseline-balancing
• Egyptian Hieroglyphs
• Dotted handwriting font
• Embedded rasterization

52

Beyond Emulation: SIL Graphite2

• 90kb wasm payload (40kb in WOFF2)
• 3x slower than native, with JIT

53

Beyond Emulation: Arabic collision-avoidance

54

Beyond Emulation: Arabic baseline-balancing

55

Beyond Emulation: Egyptian Hieroglyphs

56

Beyond Emulation: Dotted Handwriting Font

57

Beyond Emulation: Embedded rasterization

58

Beyond Emulation: BIG question, again:

Why?

59

Beyond Emulation: Take Arabic typesetting

• Graphite
• DecoType
• DigitalKhaatt
• Other custom-built solutions, some only available in Iran / Pakistan

​

• We don’t want to standardize one solution. It would be way too specific for a general font format.

60

Beyond Emulation: Interpretations

• Pluggable shapers
• For typesetting
• Universal extension mechanism
• Finally putting the smart in fonts

61

Beyond Emulation: Precedent

• Graphics: OpenGL Shading Language, WebGPU Shading Language

​

• The Web: Javascript, WebAssembly

​

• Web serving: Containers, Wasm in Edge Computing

​

• Typesetting: TeX, luaTeX

62

Beyond Emulation: A philosophical debate

• AAT / Graphite chose a state-machine approach to shaping.
• OpenType chose a per-script shaping model.
• The OpenType approach proved hard to scale, so the Universal Shaping Engine was born.
• It is impossible to envision all needs and encode them in the font format.
• The choices are to either give up, or enable arbitrary computation.
• As demonstrated already, OpenType lookups are Turing-complete; just tedious to work with, as is the Turing machine itself.
• One Nastaliq font has a GPOS Lookup with more than 3,800 sublookups!
• The equivalent WASM font is ⅓ of the size.

63

Part 1: Boring Expansion

​

Part 2: Better Ergonomics

​

Part 3: Beyond Emulation

65

Forum 1: BE Github

​

Forum 2: ATypI & other type events

​

Forum 3: MPEG & other standards

67

68

At a future ATypI event, we feel it will be important to offer a platform to a more diverse panel, inviting both font creators and font users to give their input on how best to advance the OpenType standard.

Demos, use-cases, and critiques are essential for implementers, to motivate them to allocate resources to implement, to test their early implementations, and for them all to align and standardize.

It is important for the ATypI community to engage with font-format innovation in this way so that it may serve all participants in our industry.

​