search

readium / readium-css

🌈 A set of reference stylesheets for EPUB Reading Systems, starting with Readium Mobile
https://readium.org/readium-css/
BSD 3-Clause "New" or "Revised" License
90 stars 20 forks source link

Extend font embedding to a subset of recommended fonts? #70

Open JayPanoz opened 4 years ago

JayPanoz commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

JayPanoz commented 4 years ago

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 commented 4 years ago

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?

  1. 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 commented 4 years ago

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 commented 4 years ago

Note to self: add Literata and Open Dyslexic.