Support variable fonts

[nephele]

Fonts, generally, used to ship with several font "weights" which are stylistic variations on the same font to have a bold, fat, light appearence. etc.

The Opentype format has gained support for "variable" fonts, these are fonts that do not have seperate weights but instead include a single outline and information on how to interrpolate between weights, and what values are which "named" weight.

This has the advantage that users can pretty freely pick the exact font they want, and for us it has the advantage that it saves space. For example: the new Noto emoji font is 1,88MB in size. The weighted sizes available as standlone sizes are about 860KB each, giving a combined size of 4MB.

Currently we also ship noto cjk with 8 weights for about 17mb each, combined about 136mb. The noto cjk variants with variable weight are about 30mb in size. (ref: ​https://github.com/notofonts/noto-cjk/blob/main/Sans/Variable/OTF/NotoSansCJKjp-VF.otf) (although we should probably use the subset types and let users pick if they prefer chinese or japanese based on locale, instead of picking one cjk font that is biased there.)

[pulkomandy]

We probably shouldn't package all weights by default and split the font packages a bit (to ship only regular and bold in the default install, for example) until this is done?

[nephele]

I don't see a problem if you want to do this optimization for the default install, for haikuports however this seems like too much work (and would have to be done twice once support is finished, to then go to the variable font)

[korli]

​https://review.haiku-os.org/c/haiku/+/7402

[korli]

"users can pretty freely pick the exact font they want," is vague. Other OSes only expose the named variants plus size. To actually expose the differents variable axes, this would need API changes, support in apps, and i18n support. Is it really worth it?

[pulkomandy]

There are interesting examples of what you can do with variable fonts, for example ​https://shantellsans.com which has "informality" and "bounce" variables you can adjust as you want.

For now it is fine to offer a few well known presets matching the existing API. But it would be nice to have all these options available for advanced font use, for example in FontDemo and I guess in all desktop publishing / graphics / word processing apps.

I'm not sure how exactly the i18n support is supposed to work. Do we still expose each locale variant of the font as a separate font in app_server font list? How would a proper i18n integration work here?

[nephele]

this would need API changes, support in apps, and i18n support. Is it really worth it?

I think it definitely is. Even supporting this in the "fallback to the old api" style gives huge savings on disk space.