Font in Firefox is forced to Bitstream Vera Sans

[hackerb9]

Hello. As you probably know, when using Firefox with the current /etc/fonts/conf.d/56-emojione-color.conf, ugly things happen to the default font. In particular, even if the user has picked a specific font from the Firefox preferences, Bitstream Vera Sans will always be used.

I do not know the correct fix for this, but I have a temporary workaround. Font-config can ignore any programs that are named Firefox (or Iceweasel, for older versions of Debian GNU/Linux). Since Firefox seems to work fine without the 56-emojione-color.conf file, this is a harmless kludge.

Here's a patch:

 --- 56-emojione-color.conf.orig 2016-06-10 11:44:50.000000000 -0700
 +++ 56-emojione-color.conf 2016-08-06 09:20:57.000000000 -0700
 @@ -71,11 +71,18 @@
 </edit>
 </match>

 + <!-- XXX Firefox default font bug is somewhere below this line. -->
 <match target="pattern">
 <!-- If the requested font is sans-serif -->
 <test qual="any" name="family">
 <string>sans-serif</string>
 </test>
 + <test qual="any" name="prgname" compare="not_contains">
 + <string>firefox</string>
 + </test>
 + <test qual="any" name="prgname" compare="not_contains">
 + <string>iceweasel</string>
 + </test>
 <!-- Make Bitstream Vera Sans the first result -->
 <edit name="family" mode="prepend_first">
 <string>Bitstream Vera Sans</string>
 @@ -85,6 +92,7 @@
 <string>EmojiOne Color</string>
 </edit>
 </match>
 + <!-- XXX Firefox default font bug is above this line. -->

 <match target="font">
 <!-- If the requested font is Bitstream Vera Sans Mono -->

I apologize for not providing a correct fix, but I have not yet learned the weird fonts.conf XML language. (So far, I think the FC decision to use XML to represent a programming language is rather barfy. I'd rather they just gave me a regular language and had a "compiler" to convert it to XML.)

Versions

• Firefox-ESR 45.3.0
• Debian GNU/Linux 8, Jessie
• Latest emojione-color.conf from github.

I'm attaching the debug output from running Firefox with the environment variable FC_DEBUG=1 both with and without the patch so you can see how FC is picking the fonts.
fcdebug.prepatch.txt
fcdebug.postpatch.txt

Here is what Firefox looks like when using emojione without my patch:

Applying my patch, Firefox now uses the correct font:

[13rac1]

Since Firefox seems to work fine without the 56-emojione-color.conf file, this is a harmless kludge.

The demo page works without it because it specifically selects the font, but does: http://getemoji.com/ ?

[hackerb9]

Okay, this is kind of bizarre. It seems 56-emojione-color.conf appears to be doing the reverse of what it is supposed to. I just tested it in Firefox and found out that when I use the current version, I get the problem with Deja Vu replacing some of the Emoji with black and white versions. (I tried it on both the demo page and getemoji with the same results).

The default version:

However, after my patch...

But, when I use my patched version of the file, all the emoji show up correctly:

Curiouser and curiouser.

[13rac1]

Are you running fc-cache -f after these changes? I have had many issues with delays in the caching system like this.

[hackerb9]

I alternated changes so that as soon as the cache updated, I'd see the browser change. Usually it seems to be about 15 to 30 seconds, so I didn't have any problem.

I just tried again with fc-cache -f, with the same results. (By the way, flushing the cache manually didn't make the update happen any faster. I still had to wait about the same amount of time before the browser window updated. I think fontconfig must be using inotify or something similar so that it gets alerted as soon as the config file is edited.)

[hackerb9]

(Oops, I notice that in my first message I mistakenly left in a line about Firefox working without the entire file. I meant without the particular stanza that I am skipping over. Sorry for the confusion.)

[13rac1]

I recommend restarting Firefox between changes. It updates, but things go all wrong sometimes. More when changing glyphs though.

[hackerb9]

I double checked by restarting it after each change and it still behaved the same: the current conf file has the DejaVu smiley faces but when I remove (or make conditional) that stanza, as suggested in my first patch, it works fine. And, of course, my patch also fixes the problem with the Bitstream Vera overriding the default font in Firefox.

Are you not seeing the same behavior on your machine? What version of Firefox are you using? Do you have the DejaVu fonts installed?

[pelegm]

I am not 100% sure this is the same issue, but I have a similar problem on my Ubuntu 14.04 with Firefox. Each time after installing this package (via the ppa) the default font in Firefox (including but not limited to the font appearing on the tabs) starts looking weird (especially the spacings). In some websites (stack exchange, wolfram alpha) this causes the page to look horrible. I'll add a couple of images.

[pelegm]

Compare this with:

[13rac1]

@pelegm That's a known issue: https://github.com/eosrei/emojione-color-font#known-issues It's bug in Firefox which you can correct, but will cause it to crash in versions <48. The internal font list is wrong. Nothing I can do AFAIK. @hackerb9 It is related to this issue.

Are you not seeing the same behavior on your machine?

No. Please test it with a stock 16.04 ISO in Virtualbox. You don't need to install to the virtual disk, the Live CD works fine. I know exactly how it works on Ubuntu 14.04/16.04 and Fedora 22.

What version of Firefox are you using?

48, the current repo version.

Do you have the DejaVu fonts installed?

Yes. Stock Linux Mint 18/Ubuntu 16.04 fontconfig, plus my PPA.

Related, it's actually not Bitstream being disabled. If you open the fonts and look at the glyphs they are exactly the same as DejaVu. Haha, so much fun! That's why this is distinctly a Firefox problem. If you set gfx.font_rendering.fontconfig.fontlist.enabled to false it displays everything correctly.

I've been extremely busy and haven't been able to test your config until now. Your font config additions, as you know, disable the font pattern matching for sans-serif in Firefox. I implemented it and watched the correct text fonts display on getemoji.com. I wondered why for a moment, then realized the secondary fallbacks were being used.

  <alias binding="strong">
    <family>Segoe UI Emoji</family>
    <prefer><family>EmojiOne Color</family></prefer>
    <default><family>sans-serif</family></default>
  </alias>

That page specifically calls out font-family: Segoe UI Emoji; in the CSS.

So, I tried another page that requires the existing fallback system: https://en.wikipedia.org/wiki/Emoji Ah, there we go, broken emoji. Your config:

The default config:

Note: You will see problems due to #22 on that page in the "Sample emoji variation sequences", but that's out of scope of this issue.

I'd be happy if we can figure out a permanent solution to this issue, but your current idea isn't it. Please try more ideas! Thanks!

[13rac1]

The current workaround is described in: https://github.com/eosrei/emojione-color-font#known-issues and #31.

I'm closing this for now. Please add another comment or open a PR if you have ideas for a solution. Thank you!