Extend font embedding to a subset of recommended fonts?

[JayPanoz]

I think it might be worth extending font embedding to a subset of fonts from various families that we could vouch for.

Originally posted by @HadrienGardeur in https://github.com/readium/readium-css/issues/58#issuecomment-456541887

[JayPanoz]

Hmmm as far as I can remember, there’s been 2 major factors “preventing” us from embedding fonts until now:

1. font updates – some fonts are regularly updated so recommending them and pointing to their repo was the easy way out;
2. technical constraints on some platforms – I can recall a discussion @ EDRLab during which we discussed that in the i18n context, some fonts supporting Japanese being 10 MB for instance, and some size limit popped up, which is why we turned to downloadable fonts, see https://github.com/readium/kotlin-toolkit/issues/224.

So I’m definitely not against a subset of fonts we could vouch for but the 2 constraints are tricky to say the least – kerning, hinting, support, etc. can be improved dramatically on updates so we probably want to avoid updating the repo every time a font is updated.

Originally posted in 58 (comment)

[JayPanoz]

As a not-ideal but good-enough solution, something like the postcss font grabber plugin should help keeping fonts relatively up to date – at least generating new builds would upload the latest version.

[JayPanoz]

Note I'm not sure it can download fonts from GitHub yet.

[JayPanoz]

And that would strip Open Type Features we have in the HTML5 patch, cf. https://github.com/google/fonts/issues/1582

https://github.com/readium/readium-css/blob/master/css/src/modules/ReadiumCSS-html5patch.css#L56-L87

[jccr]

Hmmm as far as I can remember, there’s been 2 major factors “preventing” us from embedding fonts until now:

1. font updates – some fonts are regularly updated so recommending them and pointing to their repo was the easy way out;

If nothing else is satisfactory.. would having a build-time script that fetches the latest versions from a CDN or something work?

2. technical constraints on some platforms – I can recall a discussion @ EDRLab during which we discussed that in the i18n context, some fonts supporting Japanese being 10 MB for instance, and some size limit popped up, which is why we turned to downloadable fonts, see readium/kotlin-toolkit#224.

We could keep this concept for the embedded fonts, as an optional module to ReadiumCSS.

So I’m definitely not against a subset of fonts we could vouch for but the 2 constraints are tricky to say the least – kerning, hinting, support, etc. can be improved dramatically on updates so we probably want to avoid updating the repo every time a font is updated.

Originally posted in 58 (comment)

Re: Open Type Features This level of detail is what I believe sets us apart, so I would be disappointed if we made a big compromise.

[JayPanoz]

This level of detail is what I believe sets us apart, so I would be disappointed if we made a big compromise.

Indeed, and it would penalise authors who use those features as well.

All I found re. PostCSS are the aforementioned font-grabber and font-magician. But those aren’t really accommodating the use-case – actually, the use case is a middle ground between those 2 plugins.

And I’m not eagerly fantasising writing and maintaining a PostCSS module for that so I guess

would having a build-time script that fetches the latest versions from a CDN or something

may well be the best option.

[JayPanoz]

Note to self: add Literata and Open Dyslexic.