Closed HadrienGardeur closed 4 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
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.
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
Hmmm as far as I can remember, thereās been 2 major factors āpreventingā us from embedding fonts until now:
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.
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.
And comparison with Georgia:
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.
As every user-installed local font Iām testing fails.
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:
User-installed local fonts are also OK in Chrome and Firefox:
However, Firefox has an issue with some glyphs e.g. "Ļ" and "Ļ":
Those are OK in Chrome:
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.
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.
@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.
Literata is now available on Google Fonts: https://fonts.google.com/specimen/Literata
Might be worth revisiting this issue?
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?
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.