987357 - support system-installed fonts in .woff format on b2g/android devices

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[Jonathan Kew [:jfkthame]]

To reduce the size of the ROM image on B2G devices, we could consider storing the "system" fonts (in the /system/fonts/ directory) in compressed .woff format instead of raw .ttf or .otf.

This will reduce the total size of the CharisSILCompact fonts from 6.4MB to 2.1MB, for example; most other fonts also show substantial savings, often of the order of 50% (with the exception of AndroidColorEmoji, whose PNG glyphs cannot be compressed very much further).

FreeType now supports .woff fonts (by decompressing them to sfnt structures internally), so we could store the fonts as .woff in the filesystem to reduce our ROM footprint. (This is dependent on the FreeType 2.5.2 update we took in bug 966795.)

There may be some performance cost to this when a font is loaded for the first time (or perhaps re-loaded if it has been discarded from any caches, etc.), so we'll want to test on actual devices to check this is acceptable. It's possible that reducing the amount of data we need to load from the filesystem to instantiate a font will compensate, at least to some degree, for the added work of decompressing it.

If we can keep the fonts in compressed form, this may reduce pressure to omit certain fonts from the builds in order to save space (bug 985363).

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: support .woff-format fonts installed in the system fonts directory on android/b2g devices.

This is the Gecko part: we just need to recognize .woff files when scanning the system fonts directory. The other part of this will be to .woff-compress the various font files in frameworks/base/data/fonts and external/moztt.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

With the fonts in OTF format, they get mmapped directly from the filesystem right? Whereas now they'll have to be decompressed into RAM. So it seems like there's a performance hit here?

Maybe we can WOFF-ify just the "rarely used" fonts? Do you know what that list is?

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #2)
> With the fonts in OTF format, they get mmapped directly from the filesystem
> right? Whereas now they'll have to be decompressed into RAM. So it seems
> like there's a performance hit here?

Yes, that's most likely true. Whether it's a good trade-off is an open question, in my mind, but it seems worth investigating/experimenting.

> Maybe we can WOFF-ify just the "rarely used" fonts? Do you know what that
> list is?

It would depend on the locale. This would relate pretty closely to the discussion in bug 985363 about which fonts are needed in which locales.

Comment 4

[Jonathan Kew [:jfkthame]]

Pushed this to inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7462bee51ec6

This enables Gecko support for .woff-compressed fonts, but doesn't actually change any of the font files we're shipping. Let's do that in separate followup bugs.

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/7462bee51ec6

Comment 6

[Joe Cheng [:jcheng] (please needinfo)]

triage: ni? Thomas for evaluation
minus for now. if this is really going to benefit tarako, please renom

Comment 7

[Michael Wu [:mwu]]

Rerequesting blocking. With this, bug 987582, bug 966795, and bug 968626, we can save about 11mb in the system image.

Comment 8

[Michael Wu [:mwu]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/6b79defe81ee