Glyphs do not render on Firefox 66 or Chrome 74 on MacOS 10.14.4

[ara4n]

Trying both the latest release and a self-built copy of the TTF, the glyphs seem to render as blanks on FF & Chrome on macOS. Safari 12.1 however works.

Poking inside the TTF using Glyph.app shows that generated glyphs seem to have no geometry on the regular base layer; only on the colour layers. Defining some geometry on the base layer seems to fix it (e.g. a bounding box, or a copy of the biggest colour layer).

I'm a bit unclear on what the right fix is for this, or how it has ended up breaking so badly. Is it to calculate a bounding box and put it in the regular layer? or something else?

[ara4n]

empirically this works...

diff --git a/layerize.js b/layerize.js
index 99399d6..ae9e886 100644
--- a/layerize.js
+++ b/layerize.js
@@ -589,13 +589,13 @@ function processFile(fileName, data) {
             ligatures.push({unicodes: unicodes, components: layers});
             // create the placeholder glyph for the ligature (to be mapped to a set of color layers)
             fs.writeFileSync(targetDir + "/glyphs/u" + unicodes.join("_") + ".svg",
-                             '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" enable-background="new 0 0 64 64"></svg>');
+                             '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 36 36"><rect width="36" height="36"/></svg>');
             codepoints.push('"u' + unicodes.join("_") + '": -1');
         }
         unicodes.forEach(function(u) {
             // make sure we have a placeholder glyph for the individual character, or for each component of the ligature
             fs.writeFileSync(targetDir + "/glyphs/u" + u + ".svg",
-                             '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" enable-background="new 0 0 64 64"></svg>');
+                             '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 36 36"><rect width="36" height="36"/></svg>');
             codepoints.push('"u' + u + '": ' + parseInt(u, 16));
         });
     });

...but it feels rather wrong (and i'm unsure if the correct bounding box should be being used, rather than putting them all in a fixed grid).

[emojifreak]

Proper bounding boxes are also required for typesetting Twemoji into PDF by ConTeXt as noted in http://tracker.luatex.org/view.php?id=1012#c1716

[yisibl]

I rebuild the font and try this file.
twemoji-colrv0.ttf.zip

[CoelWu]

I rebuild the font and try this file.
twemoji-colrv0.ttf.zip

This works perfect for me! Do you have the modified source code? Thanks. 感谢

[Mkalo]

I rebuild the font and try this file. twemoji-colrv0.ttf.zip

Would love to know what was changed too.

[laukstein]

https://github.com/mozilla/twemoji-colr/files/5939135/twemoji-colrv0.ttf.zip works on Mac Mojave Chrome v79
https://github.com/mozilla/twemoji-colr/releases/download/v0.6.0/TwemojiMozilla.ttf still has the bug.

[RobertWinslow]

Here's a COLRv0 Twemoji Font updated to Emoji 14.0
https://github.com/Emoji-COLRv0/Emoji-COLRv0/blob/main/fonts/TwemojiCOLRv0.ttf
And here's a browser test page:
https://emoji-colrv0.github.io/Emoji-COLRv0/emojitable

I built it using a version of Google's NanoEmoji tool.
It renders properly on both Firefox and Chrome on my Mac OS machine.