3

I am running PureBrowser (~= Firefox ESR 52.8.0) on PureOS (~= Debian main testing) and have fonts-noto-color-emoji-0~20180424-2 installed.

When I visit https://en.wikipedia.org/wiki/List_of_Emojis I observe that:

  • some emoji render in color (as expected)
  • some emoji render as line art, rather than full-color
  • some emoji render in color, but are far too big
  • missing emoji appear as "tofu" (as expected)

This persists after running fc-cache -f -v.

Some emoji render as line art, others are too big

If I copy and paste that text into Text Editor (gedit) the emoji appear as expected (either in colour at a regular size, or as tofu):

The same emoji appear correctly in Text Editor

Why is this happening, and how can I fix it?

  • I tried putting a fontconfig override, but Firefox (56.0 here) seems to ignore it. – Ignacio Vazquez-Abrams May 16 '18 at 12:14
  • 1
    At this point you're seeing the fallback fonts. The B+W ones are Deja Vu Sans, the small color ones are a font I don't know, and the large ones are Noto Color Emoji. No idea why they're so large though. I'd consider digging through your fontconfig config. – Ignacio Vazquez-Abrams May 16 '18 at 13:01
  • related link tracker.pureos.net/T437 – david.libremone May 17 '18 at 13:10
4

There are several issues at play here:

  • The default system font is Deja Vu Sans, it contains the black and white emoji.
  • The browser bundles its own emoji-specific font called EmojiOneMozilla.ttf (originally bundled in Firefox, also included in the PureBrowser fork), it contains color emoji. (Sidenote: Due to licensing changes, recent versions of Firefox bundle Twemoji instead.)
  • You have also installed Noto Emoji, it contains newer color emoji in a different style. The scaling of this font is handled incorrectly by the version of Firefox that PureBrowser is forked from.

When an emoji character is encountered, the browser is picking between these three fonts to decide how to render them. The order above is the order of precedence, which happens to also be an order of increasing coverage, so older/common emoji are rendered in Deja Vu, more recent emoji in Emoji One, and cutting-edge emoji in badly-scaled Noto Emoji.

The "correct" solution is to fix the browser and/or Noto so that the scaling of Noto emoji in the browser is correct. Additionally, update the font hinting so that color emoji symbols are preferred over the system default font. Resolving these problems is non-trivial. For starters see:

In the meantime, one workaround is to replace EmojiOneMozilla.tff with a color emoji font that scales correctly and has equal or better symbol coverage than Noto:

Now the Noto emoji symbols do not appear, because the Twemoji TTF has equal emoji coverage. If Noto coverage improves and your Noto package gets updated, the problem will recur for any new emoji symbols. At that point you will have to wait for a new Twemoji/eosrei release and reapply the workaround.

If your PureBrowser package gets updated, it may re-add EmojiOneMozilla.ttf, in which case you will have to delete it again. It may remove TwitterColorEmoji-SVGinOT.ttf, in which case you will have to re-add it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.