Page MenuHomePhabricator

Unicode-Character 🤣 not rendered in SVG
Open, LowestPublicBUG REPORT


What happens?:
Rendering of "🤣" in is wrong

What should have happened instead?:

Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc:

wrong rendering by wikimedia-librsvg 2.40.X (end of life in 2017)

correct rendering locally with librsvg 2.50.3



Author : ( @RazrFalcon )

License: MIT-Expat-License:

Event Timeline

Actually the file is from a SVG-test, decalring that
*chrome/firefox/librsvg 2.51 renders it correct
*resvg/inkscape/batik and others render it wrong

Rendering of resvg on my local computer results in

So I think it is a sub-task of T193352 and not a font-Problem?

It looks like a font issue to me, and I do not see any of the images as "wrong".

All 4 characters are above the basic plane.
U+1F600, U+1F601, U+1F602, U+1F923.
That suggests the SVG agents have no problems rendering high plane characters.

In the first picture, the fourth character is a format that is often used for unimplemented characters.

The second picture shows a font that has colored characters instead of the black-and-white characters of the first.

The SVG file specifies font-family="Noto Color Emoji". Noto signifies a Google font.

You should be able to download that font at

Definitely a font issue, probably not a librsvg issue. Debian doesn't package Noto Color Emoji until Buster, so we'd have to backport (unlikely) or wait for T216815.

Yes this character seems to be a font-issue. However it is strange, why now resvg does not render any characters any more on the same computer (I run in the meantime sudo dnf install google-noto-\*)