- Chris Lilley, W3C
- Introduction
- Motivating Use Cases
- Non-goals
- Considered alternatives
- Incremental Font Transfer
- Demo
- Testing
- 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.
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
The current specification draws on the Patch Subset concept of patching a font to provide more data. However, instead of requiring custom patch generation for each user, the initial font has two new Patch Map tables which map each subset definition to the link of the relevant patch. Links are stored in the font as RFC 6570 URI Templates.
Thus, static hosting of files (base fonts, and patches) is easy, and cache performance is good because patches are shared between users.
We incorporated a new idea to allow patches of glyph-only data to be independent.
(This type of patch would have been too costly to compute dynamically, but they work well with this new framework of pre-computed patches.)
This also allows independent patches to 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.
In addition, patches can add or extend design axes, to support variable fonts.
It no longer requires any special HTTP headers, or a custom protocol to fetch patches. Requests are just normal HTTP GET requests, making it easier to deploy and compatible with existing CDN infrastructure.
The main trade-off with this new approach is that the patches potentially become less granular, somewhat reducing peak efficiency, while also being more privacy-preserving.
We have a proof of concept demo of the new IFT approach.
We will work on tests; the specification marks up each testable assertion.
- Chromium : Positive
- WebKit : No signals
- Gecko : No signals
- Font Vendors (Adobe, Apple, Dalton Maag, Google) : Positive