Demo of incremental font transfer

By Garret Rieger (Google) and the W3C Web Fonts Working Group

This video demonstrates incremental font transfer working in browser to load fonts via a web assembly polyfill. Incremental Font Transfer is a new way to transfer fonts that allows for only the needed data from the original font to be loaded on demand. It will reduce transfer sizes for web fonts while maintaining full rendering correctness. Of particular note it is able to significantly reduce transfer sizes for Chinese, Japanese, and Korean fonts which are currently difficult to use without IFT due to large file sizes. The specification is currently a candidate recommendation snapshot and can be viewed here: https://www.w3.org/TR/IFT/. The demo shown in the video can be tried out here: https://garretrieger.github.io/ift-demo/

Skip ⬇

Video

Transcript

This video will provide a demonstration of Incremental Font Transfer working in a web browser.

Before we begin, just a little bit of explanation about what IFT is.

So, incremental font transfer is a W3C standard that's currently being developed by the Web Fonts Working Group, and it's currently a Candidate Recommendation snapshot.

At a high level, it allows for fonts to be used by partially transferring just the data that's actually needed to render a specific page.

This is in comparison to the more typical technique of splitting a font into multiple smaller fonts and then pulling in those individual fonts as needed.

Under the hood, this works by putting all of the bits of font data into patch files, which are then requested and applied to the font as they're needed.

Ultimately, it transfers only what's needed on demand.

So that reduces, you know, your total transfer sizes.

But because it, we aren't splitting into actual distinct font files, it maintains the correctness of the original font.

And we'll talk a little bit bit about that more during the demonstration.

So this demo currently compares IFT font loading to font loading via the unicode-range mechanism.

And so, the unicode-range mechanism takes a font that's been split into individual fonts and then loads them based on which Unicode codepoints are present.

And so, specifically it's using the Google fonts unicode-range implementation.

So the IFT client used in the demo is a WASM polyfill but it is running in browser.

All right.

And then so just before we get started, I'll just be going through a few different text samples.

And then IFT and unicode-range will be used simultaneously to load the fonts for the to display those text samples.

Okay.

So let's go to the first one here.

This is just some basic Latin text.

And then, you'll notice on the right hand side here, we have a couple of counters that are tracking how much data is being transferred using the two different methods of loading the font file.

All right.

And then so on the next text sample, this one is in Vietnamese.

And this is where we start to see some interesting differences between the two different ways of loading fonts.

So I can flip here between, I'm showing the font rendered with IFT versus unicode-range.

And you'll notice as I flip back and forth in the unicode-range version, there's a few characters that aren't actually rendering correctly versus the incremental font transfer version.

And the reason this happens is because there's character layout rules that are split between the Latin and the Vietnamese font subsets.

And because of those have been split into separate font files, they no longer work correctly, whereas incremental font transfer doesn't suffer from this because it maintains everything in a single font that always works the same way as the original, unmodified font would have worked.

Okay.

And then next we have some Cyrillic and Greek text.

So this just demonstrates pulling in some additional font data to cover these two new languages.

And then here again we can see some differences between unicode-range and IFT.

So if you look closely, you'll see that the kerning between the Latin punctuation and the Cyrillic characters is not working correctly.

And that's again because those kerning rules get broken across the Latin and Cyrillic subsets with unicode-range, whereas with incremental font transfer they're retained and work correctly.

Then this text sample shows off another unique feature of IFT.

You know unicode-range is restricted to only being able to load subsets in response to the presence of Unicode codepoints, whereas here a new capability of IFT is that it can also load patches in response to the need for layout features.

So in this case, we've pulled in the small caps character set on demand as it was needed.

And so this is a really useful functionality because you can now by default in your font, not have the small caps included and then only load it when it's actually truly needed, since it's not something that's super commonly used, whereas with unicode-range that isn't really possible.

And just to demonstrate the the Google fonts unicode-range implementation it does not even put small caps characters in the fonts to save space.

So you can see here, under unicode-range, they don't even render correctly.

And then, in addition to being able to load layout features on demand, we can also load for variable fonts design space on demand.

So, in this text sample, we've pulled in a width access to the font that we've been loading in the previous samples and added it as it was needed.

And, sort of the really interesting part of this is, this is done by just pulling in the additional variation deltas related to that, additional design space, without needing to replace the whole font as you would have to do with unicode-range if you were to change the design space that's supported.

Okay.

And next up, this is another really interesting use case for IFT.

So, this is showing off some Chinese sample text.

And so because Chinese fonts have a very large character repertoire of which you're only going to need some small subset for any given page, we can save significant amounts of data by using IFT.

And so, here you'll see that we've used quite a bit less data than the unicode-range approach.

And so while unicode-range does, you know, reduce data transfer versus the original font, it adds quite a bit of extra overhead because you have to use fairly not fine grain subsets due to the amount of just overhead in an individual font file.

Whereas with IFT, since we're using a very compact patch format, we have almost next or very small amounts of overhead per patch and so we can use much more fine grained patches and get a, you know, pretty much just the exact data that's needed for any particular text sample.

And so we just have a few more um text samples here using Chinese.

And you'll see that as we go through the different text samples, small amounts of additional data are being pulled in.

That's just as characters that haven't been seen yet are being encountered the patches for those are being pulled in on demand.

And then, next up just to demonstrate an additional language, we have some Japanese text samples and then, very similar to Chinese, the Japanese benefits a lot from IFT due again to the large character repertoire and so we're able to pull in data just for the characters that are actually on the page here. And so you can see we've transferred quite a bit less data overall than unicode-range has, which I should mention that unicode-range is already you know optimized versus what would be transferred if you're just using the single original font.

And then we have one last Japanese sample.

All right, so, in summary, you know, over the course of all these text samples we've transferred 60% less data than we would have using the current unicode-range based approach.

And we've maintained full correctness of rendering throughout all the samples which unicode-range wasn't capable of.

All right, and that's it for the demo and thank you for watching.