Nanoemoji build chain with color font outputs for desktop and web #422
Conversation
This is done via the container at https://gitlab.com/mavit/nanoemoji-container. For me, the resulting COLR TTFs work in Firefox and in the Gnome desktop on Fedora 32 (although they display rather small). Caveats: - It may be premature to replace `scfbuild` for SVG builds. If we decide to go ahead without `scfbuild`, then we’ll want to remove the remaining files related to it. If we decide to keep `scfbuild`, then we’ll want to revert those parts of this patch. In either case we’ll want to update the readme to link to the new outputs. - I’ve tested this with Podman, not Docker. Relates to hfg-gmuend#93.
Unlike Podman, Docker only supports SELinux relabelling with --volume, not --mount.
This is now possible because googlefonts/nanoemoji#114 was fixed.
Some of them still overspill slightly. Perhaps scaling by 1.3 is a bit too much?
This yields TTFs of about a quarter of the size of those generated by scfbuild.
This makes quoting more obvious and straightforward, but also ensures that variable substitutions are done inside the container, so we know the Bash version is recent enough to support the `${var^}` feature.
- Itʼs suggested in googlefonts/nanoemoji#157 that we donʼt apply scaling by transforming the root `svg` element, but rather by enclosing the body of the SVG in an element that applies the transform. - Recent nanoemoji versions are configured with a file rather than on the command line.
Make use of the new `--ascender` and `--descender` options to control the size of the characters.
|
I am running the builder now, though perhaps @b-g could rerun it on his machine to confirm everything is working once I've pushed the last commit and removed the WIP marker from the PR (likely tonight). |
|
@b-g this is ready to merge now. You may want to try and run the builder on your end again, though nothing substantial has changed and it is working nicely for me. The biggest issue is definitely the build times, though with cache it isn't terrible and it only needs to be done when making new releases. |
JeppeKlitgaard
changed the title
|
It would be helpful to merge this before too many more changes, as rebasing can be a bit laborious. Should ideally be merged ahead of #431, for example. |
|
@JeppeKlitgaard Many thanks! Near there! Yay! Comments:
|
|
|
@b-g I've fixed the shellcheck warnings. I assume running I thought I had rebased off of master and fixed any merge conflicts, but I must not have done that. I've had a look at the merge resolution you did and it all seems fine to me – I manually had a peek at most of the SVGs and the other file changes seem to be correct as well. Apologise for the inconvenience there! |
|
Hi @JeppeKlitgaard,
Yes, but I was slight confused as the generated files only appeared in the Also there very last line of the entire build process seems to report an issue Hence what about the following approach: |
|
@b-g This is definitely my fault. This bug was introduced with the multi-format font support I made over the weekend and since the build is so a fairly lengthy affair especially without cache I never did a full-rebuild which would have revealed this bug. I will push for a fix for this before the merge. It would probably be good if I could do a full rebuild myself (i.e. deleting When that is done I would feel fairly confident that the building should just work and I agree that merging this would be a good idea. Docker publishing and multi-arch builds would be a good fit for a separate PR. |
|
@b-g I have now done a full rebuild from scratch (i.e. deleting This should be mature enough to merge now. Note that merging this will close 3 issues (see right sidebar). The issues seem to have sprawled a bit in their discussions, so not entirely sure this PR actually fixes them entirely. Might be worth making new issues for the things not fixed by this, or alternatively not closing those issues. |
|
@JeppeKlitgaard gave it a go as well! Runs now smooth! Many many thanks, also to @mavit! Merged! Yay!! 🎉🎉🎉! |
Introduction
This PR continues the work of @mavit in #260 and fixes the following issues:
Fix: #93 (though this has other discussions in it as well, such as fixing "black fillings")
Fix: #413
Potentially fixes: #339
TODO
Before merge:
font/README.mdhelpers/generate-fonts.sh)SVG+COLRfonts usingmaximum_colorREADME.mdAfter merge:
zopflipngshould be disabledcbdt,sbix, etchelpers/dockerContent
This PR entirely removes the existing
scfbuildtooling for rendering fonts.scfbuildis old and abandoned whereas the replacement,nanoemoji, is actively maintained and implements a lot of features that result in smaller font file sizes and wide compatibility.We generate fonts for all the formats described below and it is up to the user to choose one that works for their application. A guide will be given in
README.mdin the future.Notes
nanoemojidoes a lot more work under the hood than thescfbuildtooling did and it takes substancially longer to run. On my machine, the initial rendering of the fonts takes more than an hour. Luckilynanoemojihas a very intelligent build system and renders much quicker for subsequent runs and automagically detects which files have changed and rerenders just those.Font formats
nanoemojiallows us to render color fonts using a wide variety of formats. A quick overview of them is given here:glyf: Standard format that is widely supportedcbdt: Bitmap format, works well for Android and old Chromium-based systems (< 98)colr_0: Widely supported color format that works in all modern browsers, but lacks some support for advanced features like gradientscolr_1: The emerging standard for color fonts, but not yet supported by Safari and many desktop applicationssbix: Apple-centric format that is supported in Safari and some MacOS appssvg: Previously preferred and championed by Apple and Mozilla. Not supported by Chromium-browsers, but works in Safari and FirefoxSupport
For an overview of which applications support which formats, have a look at colorfonts.wtf, caniuse/colr, and caniuse/colr_v1
Demo
I've now updated my own site to use the generated OpenMoji fonts. Those who are particularly curious can have a look here: https://jeppe.science/
The emojis have a bit more space around them than the
twemojiI was using before. This means that the emoji become quite small in regular text and can be somewhat hard to make out, in my opinion. This can possibly be changed by modifying theascenderanddescendersizes?