Generate WOFF2 fonts for use on websites

[JeppeKlitgaard]

Now that the color wars are approaching an end with COLRv1 appearing to be the emerging standard, we're approaching a point where OpenMoji could possibly be used on websites – I am quite keen to try this on my own site. Ideally a version targeting websites would be made available using WOFF2 for compression.

I am currently working on setting up a build environment for this.

[JeppeKlitgaard]

It works on a Chromium-based 107+ browser using COLRv1 and WOFF2.
It doesn't work on Firefox 107 using COLRv1 and WOFF2 or TTF (even though caniuse suggests it should?)

With WOFF2 the font is just shy of 1MB.

[b-g]

That's great! Please let us know how it goes, see also the endless saga of #260 ... and the current build process of the fonts in https://github.com/hfg-gmuend/openmoji/blob/master/helpers/generate-fonts.sh

[JeppeKlitgaard]

I am currently working on a small issue with picosvg over at googlefonts/picosvg#278, but if we get that fixed it should be possible to finally sunset scfbuild

[JeppeKlitgaard]

Additionally since nanoemoji leverages the ninja build engine, I think we could tear out the old build system caching system, which would solve #403.

[b-g]

The build system caching is completely independent of generating the fonts. I don't see any connection to the fonts. It simply helps to only generate pngs, format svgs etc. only for changed files.

In principle sun setting scfbuild would be great. But after several efforts of trying to do so, I'm quite disillusioned whether the color font wars are really at the end. Please note that we will only accept a new font build system if it is really bullet proof. I have to say that I'm personally tired of wasting any more on the color fonts. Again: we are busy with emojis, this is the core of the OpenMoji project, the fonts are only nice to have and are burden in terms of time and energy. Sorry for not being more cheerful on this end.

[JeppeKlitgaard]

I'm slightly more optimistic, partly on the back of COLRv1 now being implemented in all major browsers except Safari and Google making really good progress on their color font stuff - Noto Emoji seems to be a priority for them.

The ninja build system has a caching system with dependency resolution built in, essentially giving us the caching for free (and perhaps also more robustly). Changing this over would be an incremental change, as I believe nanoemoji and the existing build caching system can work together. I agree that this is not something that should be pursued now, but could be an alternative long-term solution to #403 . completely understand the frustration that I am sure you've felt around tooling, but I also feel that the best way to avoid more frustrations in the future will be to try and leverage as much tooling developed elsewhere as possible. If we can use much of the same tooling that Google uses for Noto Emoji, that would give us a really robust, long-term solution for very little effort (once changed over).

[b-g]

OK. Many thanks for the explanation! Great that your are optimistic! :) Happy to review a PR etc.

Please note also, contributors come an go (which is great and much appreciated) but at the very end someone aka me will have to deal with any technical debt. As I'm busy with a lot of other things e.g. teaching / researching at my uni ... We won't be accepting anything which seems fancy now, but likely introduce even more work for us or has an uncertain future. Yes, what we have is bare metal and partly crappy ... but it works and we can deal alone with the complexity without having to rely on external contributors.

I'm just very upfront with my grumpy pragmatism, to not disappoint you. Please make sure to not potentially "waste" any time on this ... again we stopped investing any time into this issue after lots of wasted efforts.

[JeppeKlitgaard]

Oh no, I definitely appreciate that!

Would you (no guarantees given, of course) take a PR that:

1. Replaces scfbuild with nanoemoji (assuming this works)
   • This is for generation of TTF's with OT-SVG format and COLRv0 and COLRv1 (possibly also other formats supported by nanoemoji)
   • This would use a docker container, which is of equal complexity to the current approach
   • Additionally generates WOFF2 files from the TTFs

[b-g]

That would be very lovely! 🤞

One last note and esoteric requirement: as our audience involves a lot of designers ... it it important that at least one of the OpenMoji-fonts can be used in the current dominant tools like the Adobe CC Indesign. This works also with scfbuild. We are not a big fan of those, but it really helps in terms of designing all kind of things with OpenMoji.

[JeppeKlitgaard]

I'll create a new issue where we can test the output from nanoemoji across various setups. I don't have any Adobe licenses and Apple devices, so I will need some help testing whether it works on those systems. I do believe the issues around Adobe products has been sorted out in picosvg a while ago.

[b-g]

👍 ! (Yes ... we can take care of checking in Adobe CC)