- Chris Lilley, W3C
- Introduction
- Motivating Use Cases
- Non-goals
- Incremental Font Transfer
- Demo
- Testing
- Considered alternatives
- Stakeholder Feedback / Opposition
Web Fonts allow web pages to download and use fonts on demand, without the fonts needing to be installed.
Incremental transfer allows clients to load only the portions of the font they actually need which speeds up font loads and reduces data transfer needed to load the fonts. A font can be loaded over multiple requests where each request incrementally adds additional data.
WebFont usage is high globally, around 75% of top-level web pages use it.
However, WebFonts are currently primarily used with simple writing systems such as Latin, Greek and Cyrillic where the median WOFF2 size is 8.3kB
For fonts with many glyphs (such as are typically used for Chinese and Japanese, for example), even with the compression provided by WOFF 1 or 2, download sizes are still far too large with a median WOFF2 size of 1.8MB. Thus, usage of Web Fonts in China and Japan is close to zero.
For languages with a small set of glyphs, static font subsetting is widely deployed.
However, for those languages with complex shaping requirements,
static subsetting gives small files (median WOFF2 size of 93.5kB)
but when combined with CSS unicode-range
is known to sometimes produce malformed, illegible text.
Static subsetting fails when there are complex inter-relationships between different OpenType™ tables, or when characters are shared between multiple writing systems but behave differently in each one.
Current subsetting does not address subsetting design axes (variable fonts).
Changes to the Open Font Format or OpenType specifications are out of scope.
Web pages that wish to use an IFT font
use the regular CSS @font-face
mechanism,
and opt-in
with tech(incremental)
or by using font-tech(incremental)
inside an @supports
rule.
This allows the same CSS file to link to an IFT font
and to some (larger, slower) fallback font.
The link in the src
descriptor points to an
IFT font,
which is a regular OpenType font;
this is commonly encoded as WOFF2 for efficient transfer.
It containins only the data needed to correctly render some subset of:
- code points,
- layout features
- design-variation space
This subset also contains extra tables which carry patch maps. which map subset definitions to the link of the relevant patch. Links are stored in the font as RFC 6570 URI Templates.
In contrast to static font subsets, these links allow font patches to be downloaded on demand and applied to the initially downloaded font, to support additional code points, layout features, or variation spaces.
For example, an IFT font might support only Latin characters, with a single weight. But the font also provides URLs for patches that add a weight variation axis, or add small caps, or support Cyrillic characters. These would be downloaded and applied on demand, as content is encountered that needs them.
This avoids the rendering breakage often encountered with complex writing script languages such as Arabic and Indic languages, when multiple static subsets are used together.
It also allows webfonts to be used for languages such as Chinese and Japanese, because glyphs for additional codepoints are only downloaded when they are actually needed.
In this architecture, static hosting of files (IFT fonts, and patches) is easy, and cache performance is compatible with existing CDN infrastructure because patches are shared between users. It is also also more privacy-preserving (compared to other approaches which were considered, see below).
As a performance optimization, IFT allows patches for glyph-only data to be independent, Meaning they can be requested in parallel, which functionally is very similar to how unicode range webfont loading works.
Thus, both independent (commutative) and dependent (non-commutative) patches are supported.
We have a proof of concept demo of the new IFT approach.
We will work on tests; the specification marks up each testable assertion.
A 2020 Evaluation Report simulated performance with two strategies: Range Request and Patch Subset.
Performance was simulated on different speeds of network (from fast wired to 2G), for three classes of writing system (simple alphabetic, complex shaping, and large) and for two methods (Range Request and Patch Subset, see below).
Both size (total bytes transferred, including overhead) and network cost (impact of latency on time to render) were considered.
These initial approaches informed the current specification, but the WG ended up discarding one and substantially rewriting the other.
The Range Request method relied on the existing HTTP Range Request functionality and therefore could be used with any HTTP server. For best efficiency, the font needed to be re-ordered before upload to the server.
The client still needed to be updated to support this method.
Work on Range Request was discontinued because:
- Performance was insufficient in general
- Only glyph outlines were subsetted
- On slower networks, Range Request was worse then no subsetting at all
The Patch Subset method required the server to dynamically respond to a PatchRequest by validating the request, computing a binary patch between the current, subsetted font on the client and the desired subset of the original font, and then sending the patch, which the client applied to produce a new, enlarged subset font.
It therefore required new server capabilities, in addition to client changes.
Work on Patch Subset was discontinued because, despite median byte reductions of 90% for large fonts,
- The dynamic subsetting severely impacted CDN cache performance
- Subsetting fonts with complex interactions between glyphs was challenging
- Requiring an intelligent, dynamic server hindered widespread deployment
- Very fine-grained subsetting might be a privacy violation
- It required a custom protocol (and HTTP header) to communicate with the dynamic backend
- Chromium : Positive. Implementation
- WebKit : No signals. Request for Position
- Gecko : No signals. Request for Position
- Font Vendors (Adobe, Dalton Maag, Google) : Positive