Build COLR TTFs with nanoemoji

[mavit]

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 #93.

[mavit]

Any feedback?

[carlinmack]

This is super cool! I think @b-g would be responsible for testing this with the other fonts.

In the meantime, could you attach some screenshots?

Thanks so much!

[mavit]

[carlinmack]

wow the quality is so much higher than we've ever had! Thank you for making them larger too, we still need to figure out what option we want to choose (#112 #257), but I think the size you have used is pretty good

[mavit]

I took the 1.3 scaling factor from d66343ea2cb92a33bb8f969b8eff0cc5976d4d70, although I think it looks a little cramped and would be tempted to go for something smaller.

[b-g]

Dear @mavit! This is mega!

My apologies for the very long radio silence over the summer ... but I needed a break with the OpenMoji project :)

I totally would love to swap scfbuildwith your version of nanoemoji! scfbuild is no longer actively maintained and this in contrast with a very active nanoemoji project (backed/funded by Google) makes at least for me the decision very easy.

I've tried to build the fonts with npm run generate-font but failed. It would be important that the colorfont generator stays accessible in terms complexity and operation systems. A lot of the people on the project are not coding experts but eventually need to generate the fonts.

Could you check ./helpers/generate-fonts.sh: line 39: OpenMoji-${saturation^}: bad substitution so that I could give it a try as well?

bene@zwei-207 openmoji % npm run generate-font

> [email protected] generate-font /Users/bene/Documents/openmoji
> ./helpers/generate-fonts.sh

👉 generate-font-css.js
master: Pulling from mavit/nanoemoji-container
c7def56d621e: Pull complete 
f2931b91d78b: Pull complete 
f6b4b8ceb868: Pull complete 
Digest: sha256:77b71ae860417e531c72870d17128e878b87a8989479e7010073e607d04a937c
Status: Downloaded newer image for registry.gitlab.com/mavit/nanoemoji-container:master
registry.gitlab.com/mavit/nanoemoji-container:master
./helpers/generate-fonts.sh: line 39: OpenMoji-${saturation^}: bad substitution
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] generate-font: `./helpers/generate-fonts.sh`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] generate-font script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/bene/.npm/_logs/2020-10-15T07_18_22_557Z-debug.log

[mavit]

I'm guessing you're using MacOS, here, because it turns out that that has an ancient version of bash which doesn't support the ${variable^} feature. I'll move this substitution into the container, where we have a known version.

[carlinmack]

you should shellcheck your bash scripts, it's helpful for catching stuff like this :)

[mavit]

you should shellcheck your bash scripts, it's helpful for catching stuff like this :)

This is good advice, but I do, and it doesn't help here: ShellCheck knows that ${variable^} needs Bash, but we are using Bash, so it doesn't warn.

[b-g]

Yes I'm on macOS, using zsh (note: 10.15 Cataline replaced bash with zsh).

% zsh --version
zsh 5.7.1 (x86_64-apple-darwin19.0)

Still the same error.

Yes would be great to move as much as possible inside a fully controlled docker image.

[mavit]

Yes I'm on macOS, using zsh (note: 10.15 Cataline replaced bash with zsh).

/bin/bash will get used anyway, here, since that's what's specified on the #! line of the script.

Still the same error.

Sorry, I overlooked a second place where this syntax was used. Please try it again.

[b-g]

Many thanks for the recent fixes! I'm able to run it now!

First impression is good! Can't spot any difference if I use demo.html:

scfbuild	nanoemoji

However if I'm using your generated demos I get some bugs (why?):

• Big color emojis are cropped
• Black notebook is broken
• Black stroke weight is not always the same

Will also ask @dnlutz to import the files in a font editor to cross check everything ...

OpenMoji-exported_nanoemoji.zip

And it is worth pointing out that the font files have a massively smaller footprint in terms of files size:

• OpenMoji-Black.ttf 9.4 MB vs 1.4 MB
• OpenMoji-Color.ttf 13.6 MB vs 2.2 MB

This seems to almost magic :)

[mavit]

However if I'm using your generated demos I get some bugs (why?):

* Big color emojis are cropped
* Black notebook is broken

I don't see these issues in Firefox for Fedora Linux. I wonder if this is related to the capabilities of the OS's font rendering. Are you using the SVG or the COLR/CPAL font, here?

Scaling the glyphs up to 130% causes them to overspill their bounding boxes, so, to be honest, I was surprised when I tried it and they didn't appear cropped for me.

* Black stroke weight is not always the same

I do see this issue. I've tried building with nanoemoji's untouchedsvgz format (edit line 50 of generate-fonts.sh) and it seems to fix the stoke weight issue for me for the SVG font. Hence, this seems to be a bug in picosvg.

[dnlutz]

the overall curve quality looks much better now, thank you very much ; )

on my mac the color version works in textedit … but not in all those adobe applications (indesign, illustrator, photoshop). the black version is working perfect but it doesn't display the color version.

generally all major adobe applications should support ot-svg-color fonts by now: https://helpx.adobe.com/fonts/user-guide.html/fonts/using/ot-svg-color-fonts.ug.html

do you have any idea what might cause this error?

[mavit]

on my mac the color version works in textedit … but not in all those adobe applications (indesign, illustrator, photoshop).

Is this with the COPR/CPAL TTF, or the SVG TTF? I think it’s likely that we’ll want to recommend one format of TTF for certain OSs/applications and another for others.

the black version is working perfect but it doesn't display the color version.

I'm not sure what you mean by this?

[dnlutz]

it's the OpenMoji-Color.ttf font from OpenMoji-exported_nanoemoji.zip that doesn't work in the adobe applications.

it shows up the font menu but it doesn't display any glyphs : /

[b-g]

@dnlutz please check again the newly exported fonts, especially the CPAL ones: exported-openmoji-fonts-21-oct-2020.zip

@mavit Great! Building the fonts works nicely now. But we have to double check the quality ... and the maybe settle down on a single approach? Hence here is a list of how the current fonts are rendered in various browsers

Current OpenMoji fonts of 12.4

(firefox, chrome, safari)

Work in progress OpenMoji fonts of this PR

(firefox, safari, chrome)

[dnlutz]

unfortunately nothing works in indesign : / the only version that shows up in the glyphs-palette is from the folder "untouchedsvgz" but if it type something there are only empty white glyphs. and if i rescale the glyphs-palette the glyphs also disappear.

[dnlutz]

maybe we should reach out to @pauldhunt from adobe? @RoelN also seems to be quite familiar with the subject …

[b-g]

@dnlutz but the one of OpenMoji 12.4 works in Adobe CC?

[dnlutz]

yes … after a reboot it works again ; )

[mavit]

The stroke width issue described in https://github.com/hfg-gmuend/openmoji/pull/260#issuecomment-710012849 turned out to be a bug in picosvg which is now fixed.

Hereʼs a summary of what I believe to be the current situation:

• Both the colour COPR/CPAL TTFs and black and white TTFs built by nanoemoji work well on Linux, but do not work well on MacOS. ~~I donʼt believe theyʼve been tested on Windows.~~ They work on Windows too.
• The colour SVG TTFs built using nanoemoji work adequately in Firefox but not sufficiently well in other applications. They're probably not useful to us at the current time.
• The existing TTFs generated by scfbuild are much larger than those generated by nanoemoji, but are more compatible with various applications.

~~Does anyone have a computer running Windows they could test on?~~

[RoelN]

The CPAL font looks fine on Windows (shown here in Wakamai Fondue in Edge 87 on Windows 10)

[b-g]

Hi @mavit, that's good news + Many thanks for the update!

Just wanted to give it a try as well ... but getting this error now (see below).

Also could you do me a favor and make the filenames of the resulting fonts more verbose? I feel it is not so clear what for instance the file picosvgz/OpenMoji-Color.ttf actually holds in terms of standards. I think a filename like OpenMoji-Color-COPR-CPAL, OpenMoji-Color-SVG could streamline a little bit our discussion here. What do you think?

bene@zwei-207 openmoji % npm run generate-font

> [email protected] generate-font /Users/bene/Documents/openmoji
> ./helpers/generate-fonts.sh

master: Pulling from mavit/nanoemoji-container
ae7b613df528: Pull complete 
9970cf8663a9: Pull complete 
8f542e7556d7: Pull complete 
Digest: sha256:a38cd4692f0a104a9b2e002566a041d0d3f5fe012e10d4a8ab1de180674664af
Status: Downloaded newer image for registry.gitlab.com/mavit/nanoemoji-container:master
registry.gitlab.com/mavit/nanoemoji-container:master
FATAL Flags parsing error: Unknown command line flag 'color_format'
Pass --helpshort or --helpfull to see help on flags.
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] generate-font: `./helpers/generate-fonts.sh`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] generate-font script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/bene/.npm/_logs/2020-11-30T10_23_51_450Z-debug.log

full log file: 2020-11-30T10_23_51_450Z-debug.log.zip

[b-g]

Dear @mavit, just a random thought in terms of the bbox crop issue the COPR-CPAL fonts seem to have (at least on macOS).

Could it simply be that in helpers/generate-ttf.sh we have to alter the viewBox attribute from 72 to 1.3 * 72 = 94 ... in order to make it display nicely everywhere. Did you try that?

[mavit]

but getting this error now (see below).

Are you using the latest commit on this branch?

Also could you do me a favor and make the filenames of the resulting fonts more verbose?

Done.

Could it simply be that in helpers/generate-ttf.sh we have to alter the viewBox attribute from 72 to 1.3 * 72 = 94 ... in order to make it display nicely everywhere. Did you try that?

The font is scaled relative to this box, I think, so ultimately it doesn't help. It cures the clipping issue, but takes us back to the situation where the characters are too small.

[b-g]

Hi @mavit, Many thanks for the latest improvements, this helps! I'm able to run it again on macOS. Could you also at the scaling up of the viewbox attribute to 72 to 1.3 * 72 = 94? I think it still worth to look into it and double check what the outcome would be exactly. Thanks!!

[mavit]

Could you also at the scaling up of the viewbox attribute to 72 to 1.3 * 72 = 94

I tried it and it was as I described: the characters are too small.

[samhocevar]

FYI, I have tested the COLR/CPAL font in Emoji.Wpf, a library that adds emoji support to WPF applications on Windows, and they work pretty well except for the bounding box issues. Here are two screenshots:

[b-g]

Hi @samhocevar, very nice! Emoji.Wpf 👍 ! I guess the bounding box issue could potentially be fixed by altering the viewBox attribute, see https://github.com/hfg-gmuend/openmoji/pull/260#issuecomment-737849368 ... I currently don't have time for it, but we are planing to re-visit the issue this summer. Feel free to propose something if you are by any chance into it ;)