Why are some emoji B&W and others too big?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
2
down vote

favorite












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?







share|improve this question





















  • I tried putting a fontconfig override, but Firefox (56.0 here) seems to ignore it.
    – Ignacio Vazquez-Abrams
    May 16 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 at 13:01











  • related link tracker.pureos.net/T437
    – d3vid
    May 17 at 13:10














up vote
2
down vote

favorite












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?







share|improve this question





















  • I tried putting a fontconfig override, but Firefox (56.0 here) seems to ignore it.
    – Ignacio Vazquez-Abrams
    May 16 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 at 13:01











  • related link tracker.pureos.net/T437
    – d3vid
    May 17 at 13:10












up vote
2
down vote

favorite









up vote
2
down vote

favorite











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?







share|improve this question













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?









share|improve this question












share|improve this question




share|improve this question








edited Aug 10 at 13:17
























asked May 16 at 11:58









d3vid

726426




726426











  • I tried putting a fontconfig override, but Firefox (56.0 here) seems to ignore it.
    – Ignacio Vazquez-Abrams
    May 16 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 at 13:01











  • related link tracker.pureos.net/T437
    – d3vid
    May 17 at 13:10
















  • I tried putting a fontconfig override, but Firefox (56.0 here) seems to ignore it.
    – Ignacio Vazquez-Abrams
    May 16 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 at 13:01











  • related link tracker.pureos.net/T437
    – d3vid
    May 17 at 13:10















I tried putting a fontconfig override, but Firefox (56.0 here) seems to ignore it.
– Ignacio Vazquez-Abrams
May 16 at 12:14





I tried putting a fontconfig override, but Firefox (56.0 here) seems to ignore it.
– Ignacio Vazquez-Abrams
May 16 at 12:14





1




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 at 13:01





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 at 13:01













related link tracker.pureos.net/T437
– d3vid
May 17 at 13:10




related link tracker.pureos.net/T437
– d3vid
May 17 at 13:10










1 Answer
1






active

oldest

votes

















up vote
4
down vote



accepted










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:



  • https://github.com/googlei18n/noto-emoji/issues/36

  • https://superuser.com/questions/1111369

  • https://github.com/eosrei/emojione-color-font/issues/17

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:



  • Download the latest Twemoji/eosrei release from https://github.com/eosrei/twemoji-color-font/releases (in zip format)

  • Extract TwitterColorEmoji-SVGinOT.ttf

  • Delete /usr/lib/purebrowser/fonts/EmojiOneMozilla.ttf

  • Copy TwitterColorEmoji-SVGinOT.ttf into that folder

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.






share|improve this answer























    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f444141%2fwhy-are-some-emoji-bw-and-others-too-big%23new-answer', 'question_page');

    );

    Post as a guest






























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    4
    down vote



    accepted










    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:



    • https://github.com/googlei18n/noto-emoji/issues/36

    • https://superuser.com/questions/1111369

    • https://github.com/eosrei/emojione-color-font/issues/17

    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:



    • Download the latest Twemoji/eosrei release from https://github.com/eosrei/twemoji-color-font/releases (in zip format)

    • Extract TwitterColorEmoji-SVGinOT.ttf

    • Delete /usr/lib/purebrowser/fonts/EmojiOneMozilla.ttf

    • Copy TwitterColorEmoji-SVGinOT.ttf into that folder

    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.






    share|improve this answer



























      up vote
      4
      down vote



      accepted










      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:



      • https://github.com/googlei18n/noto-emoji/issues/36

      • https://superuser.com/questions/1111369

      • https://github.com/eosrei/emojione-color-font/issues/17

      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:



      • Download the latest Twemoji/eosrei release from https://github.com/eosrei/twemoji-color-font/releases (in zip format)

      • Extract TwitterColorEmoji-SVGinOT.ttf

      • Delete /usr/lib/purebrowser/fonts/EmojiOneMozilla.ttf

      • Copy TwitterColorEmoji-SVGinOT.ttf into that folder

      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.






      share|improve this answer

























        up vote
        4
        down vote



        accepted







        up vote
        4
        down vote



        accepted






        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:



        • https://github.com/googlei18n/noto-emoji/issues/36

        • https://superuser.com/questions/1111369

        • https://github.com/eosrei/emojione-color-font/issues/17

        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:



        • Download the latest Twemoji/eosrei release from https://github.com/eosrei/twemoji-color-font/releases (in zip format)

        • Extract TwitterColorEmoji-SVGinOT.ttf

        • Delete /usr/lib/purebrowser/fonts/EmojiOneMozilla.ttf

        • Copy TwitterColorEmoji-SVGinOT.ttf into that folder

        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.






        share|improve this answer















        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:



        • https://github.com/googlei18n/noto-emoji/issues/36

        • https://superuser.com/questions/1111369

        • https://github.com/eosrei/emojione-color-font/issues/17

        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:



        • Download the latest Twemoji/eosrei release from https://github.com/eosrei/twemoji-color-font/releases (in zip format)

        • Extract TwitterColorEmoji-SVGinOT.ttf

        • Delete /usr/lib/purebrowser/fonts/EmojiOneMozilla.ttf

        • Copy TwitterColorEmoji-SVGinOT.ttf into that folder

        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.







        share|improve this answer















        share|improve this answer



        share|improve this answer








        edited Jul 20 at 12:33


























        answered Jul 17 at 11:09









        d3vid

        726426




        726426






















             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f444141%2fwhy-are-some-emoji-bw-and-others-too-big%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?