Fix right-facing wheelchair emojis

[12Me21]

I used a script to generate them from the left-facing originals.

Some of the elements weren't flipped properly before, e.g:

---

Note: I updated the png renders with:

rsvg-convert -w 72 -h 72 ./assets/svg/"$1".svg -o temp.png
pngquant --speed 1 -f --quality 50 --output ./assets/72x72/"$1".png -- temp.png

which seems to produce similar size/quality to the existing files?

[Nerixyz]

Thank you. Should mention that #77 introduced this. Seems like an imagemagick bug.

Some of the elements weren't flipped properly before

Some of the images weren't generated properly before

[12Me21]

Thank you. Should mention that #77 introduced this. Seems like an imagemagick bug.

oh I should clarify, this is an issue with the svg files themselves. (the png renders were accurate to the svgs)
the problem seems to be that they added a transform attribute to all elements, including <g>, which means the flip got applied twice to any nested elements (like, <g transform="…"><circle transform="…"/>…</g> etc.)

[RealityRipple]

These SVGs don't render correctly when built into a font (such as Twemoji Mozilla). They result in a mangle that looks something like this:

[Nerixyz]

These SVGs don't render correctly when built into a font (such as Twemoji Mozilla).

Built a COLRv1 and SVG font with nanoemoji and the emojis display fine. It might be your SVG renderer.

COLRv1:

SVG:

[12Me21]

if it's mangling these emojis in that way, there's likely a problem with your font pipeline (specifically in the way it removes overlaps and corrects the direction of contours). are you sure this doesn't happen with any other emojis?
i've tested this with my own COLRv0 font (which is a distant fork of Twemoji Mozilla) and it works fine

[RealityRipple]

It's all a standard build with grunt-webfonts. Works perfectly fine with all the SVGs currently in the set. Also works fine if I use the older set with the newer wheel locations: grunt-compat.zip

[Nerixyz]

It's all a standard build with grunt-webfonts.

I tried this with grunt-webfonts and the resulting font isn't a color font (all glyphs are black and white). Maybe your build is not that standard. Assuming your build is also using svg2ttf under the hood, you might be running into https://redirect.github.com/fontello/svg2ttf/issues/44.

[RealityRipple]

Here's my fork of the twemoji-colr project I'm using: https://github.com/RealityRipple/twemoji-colr
It uses fontforge, and it's basically the standard one Mozilla uses for Firefox, but updated for python 3 and with zero-width character support.

[12Me21]

Here's my fork of the twemoji-colr project I'm using: https://github.com/RealityRipple/twemoji-colr It uses fontforge, and it's basically the standard one Mozilla uses for Firefox, but updated for python 3 and with zero-width character support.

ahhh it looks like the problem is that decodePath() in layerize.js can't parse svg path strings with whitespace in them (all the current files in twemoji have been "optimized" and don't contain any, but the ones in this pull request haven't yet). this causes it to fail to compute bounding boxes, and so it's not able to prevent overlapping layers.
specifically this line:

var matches = d.match("^\s*([MmLlHhVvCcZzSsTtQqAa])");

there is a missing backslash, it should be \\s

(though really, all this extra work is only necessary because the grunt-webfonts package is not designed to handle arbitrary svgs (it requires all the paths to be non-overlapping and/or have a consistent winding order). the twemoji-mozilla pipeline is very fragile)

we should continue this conversation in your repository, if necessary

[Nerixyz]

ahhh it looks like the problem is that decodePath() in layerize.js can't parse svg path strings with whitespace in them

A pass of svgo over all SVGs should fix this (what CI would do if it ran).

[RealityRipple]

Fingers crossed the CI cleans it up, then!