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
92 stars 20 forks source link

Add support for Literata #58

Closed HadrienGardeur closed 4 years ago

HadrienGardeur commented 5 years ago

I'm submitting a feature request.

Short description of the issue/suggestion:

Literata is a high quality font for long form reading designed initially for Google Play Books: https://github.com/googlefonts/literata

It was recently open sourced and would make a wonderful addition to Readium CSS and test apps.

JayPanoz commented 5 years ago

You mean, in docs (https://github.com/readium/readium-css/blob/master/docs/CSS10-libre_fonts.md) or in RCSS itself? ā†’

Right now, the only fonts weā€™re ā€œembeddingā€ are the a11y-specific fonts, see. https://github.com/readium/readium-css/tree/master/css/dist/fonts

HadrienGardeur commented 5 years ago

What's your take on this?

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

danielweck commented 5 years ago

I've just tried Literata-Medium.ttf in r2-testapp-js on MacOS (the user settings give access to both ReadiumCSS predefined font families, and the system-installed fonts). https://github.com/googlefonts/literata/blob/master/old_dropbox/_deliverables/TTF/Literata-Medium.ttf It's nice. The antialiasing makes the glyph edges look a bit "blurry", but this is something to do with Electron/Chromium on Mac, probably. You may try yourself: https://github.com/readium/r2-testapp-js/releases/tag/latest-windows-mac-linux

JayPanoz commented 5 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.

In any case I must test it with our own tool though, to make sure it is rendered properly on all platforms ā€“ itā€™s not yet available on Google Fonts so thatā€™s quite a significant signal to take into account.

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.

JayPanoz commented 5 years ago

Hmmm interesting, Iā€™m running into various issues at least on MacOS with the old deliverables (both OTF and TTF).

Safari will simply refuse to render it, Chrome is OK, some glyphs are buggy in Firefox (esp. Cyrillic + Greek). All latest versions.

Iā€™d recommend we wait for google fonts to upload it as you must currently build latest from the repoā€™s src in order to check if those issues are resolved.

Hereā€™s the generated report from Chrome, looking good in terms of support and OT features though.

capture d ecran 2019-01-23 a 13 14 47

And comparison with Georgia:

capture d ecran 2019-01-23 a 13 07 35

JayPanoz commented 5 years ago

So yeah it looks like I have a system-wide issue with user-installed local fonts in Mojave (MacOS 10.14.2). Those fonts appears OK everywhere, including word processors, DTP apps, etc., except Safari.

So this is not about Literata.

capture d ecran 2019-01-23 a 23 34 20

As every user-installed local font Iā€™m testing fails.

capture d ecran 2019-01-23 a 23 38 04

capture d ecran 2019-01-23 a 23 38 13

capture d ecran 2019-01-23 a 23 38 34

Those ones worked when I made the md doc, and theyā€™re still working otherwise. Iā€™ve tried a simple webpage and could get the same result.

Preinstalled (system) local fonts are OK:

capture d ecran 2019-01-23 a 23 44 23

User-installed local fonts are also OK in Chrome and Firefox:

capture d ecran 2019-01-23 a 23 34 25

capture d ecran 2019-01-23 a 23 34 49

However, Firefox has an issue with some glyphs e.g. "Ļ" and "Ļ•":

capture d ecran 2019-01-23 a 23 35 58

Those are OK in Chrome:

capture d ecran 2019-01-23 a 23 35 50

JayPanoz commented 5 years ago

So research tells me Safari nuked user-installed local fonts because of fingerprinting (tracking).

If you're using local in a font-face declaration even, it will consequently use an online source.

matt-curtis commented 5 years ago

I stumbled across this issue by chance, but one solution might be to establish a local server that proxies requests for those user-installed fonts.

JayPanoz commented 5 years ago

@HadrienGardeur Iā€™m postponing this a little more Iā€™m afraid.

They added a list of required changes to the GitHub repo yesterday: https://github.com/googlefonts/literata/blob/master/NOTES_JS.txt and thereā€™s still no sign of it on Google Fonts, even on Early Access ā€“ so my assumption is that they donā€™t feel it can be distributed yet.

HadrienGardeur commented 4 years ago

Literata is now available on Google Fonts: https://fonts.google.com/specimen/Literata

Might be worth revisiting this issue?

JayPanoz commented 4 years ago

Ah yes thanks for spotting the availability.

Iā€™ll add to docs first, but re.

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

I guess this is probably a good candidate for next weekā€™s call? What do people think?