1170478 - implement support for Google color emoji fonts under Linux

Status: RESOLVED DUPLICATE of bug 1264458

(Core :: Graphics: Text, defect)

Description

[Eevee (Evelyn Woods) [:eevee]]

Attachment: almost, but not quite, successfully rendering Noto Color Emoji

They *almost* work, but...

I have Noto Color Emoji installed; you can get it by cloning https://android.googlesource.com/platform/external/noto-fonts/ and copying NotoColorEmoji.ttf into ~/.fonts.

I know it works, because this demo program, which uses freetype directly: https://gist.github.com/jokertarot/7583938
produced this output: https://twitter.com/eevee/status/605653349745061889

I loaded this page: http://www.fileformat.info/info/unicode/block/miscellaneous_symbols_and_pictographs/utf8test.htm

Firefox uses Symbola, even though a color emoji font is obviously preferable.  (This might be fontconfig's problem, though.)

I changed the body's font-family to put "Noto Color Emoji" as the first choice, and got this curious output (also attached): https://twitter.com/eevee/status/605654733081092097

Not only are the colors inverted, but Firefox thinks the glyphs are /much much taller/ than they actually appear, as becomes obvious if you try to select one of them or tab among them (each cell contains a link).

I see RESOLVED FIXED bugs for supporting color emoji in OS X (bug 715798), Windows (bug 889401), and even Android (bug 974575), so I'm very sad that there doesn't seem to even be a bug for it on desktop Linux  :)

Comment 1

[Eevee (Evelyn Woods) [:eevee]]

I just thought to try this in Nightly and Aurora.

Nightly: Everything stays in Symbola.  I can't get Noto to show at all.

Aurora (both with and without e10s): Glyphs are still treated as ridiculously tall.  They render somewhat correctly now, but tinted to match the link color.  I doubt this is intentional since Android Firefox doesn't do it, and I can't figure out a way to make them show in their original colors.  (That said, it'd actually be a really neat effect to be able to opt into.)

Comment 2

[Jonathan Kew [:jfkthame]]

(In reply to Eevee (Alex Munroe) [:eevee] from comment #1)
> I just thought to try this in Nightly and Aurora.
> 
> Nightly: Everything stays in Symbola.  I can't get Noto to show at all.

That'll probably be a result of bug 1056479. cc'ing jdaggett and karlt.

John, note that Noto Color Emoji is bitmap-only, so won't be considered scalable by fontconfig; but it's pretty sad if we're losing the ability to support this on Linux. :(

Comment 3

[John Daggett (:jtd)]

Chrome ran into the same problem, since they only support scalable fonts. The new color fonts *are* scalable but older fontconfig versions view scalable == outline. The fontconfig code has been updated to add FC_COLOR and make FC_SCALABLE = (FC_OUTLINE || FC_COLOR).

https://code.google.com/p/chromium/issues/detail?id=386772
https://bugs.freedesktop.org/show_bug.cgi?id=87122

There's an explicit workaround for this:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>

  <match target="scan">
    <test name="family">
      <string>Noto Color Emoji</string>
    </test>
    <edit name="scalable" mode="assign">
      <bool>true</bool>
    </edit>
  </match>

  <match target="pattern">
    <test name="prgname">
      <string>chrome</string>
    </test>
    <edit name="family" mode="prepend_first">
      <string>Noto Color Emoji</string>
    </edit>
  </match>

</fontconfig>

We could "simulate" the above swizzling within our code but I think it's better for distros to pick up the new fontconfig to deal with this correctly.

Close as won't fix?

Comment 4

[Eevee (Evelyn Woods) [:eevee]]

I tried the workaround and it made no difference whatsoever.  Colors are inverted in stable and altered to match the text color in aurora; characters are excessively tall in both; and nightly still refuses to render the bitmap font at all.

I tried removing the "prgname" test entirely, and the only difference was that stable and aurora defaulted to Noto Color Emoji over Symbola (which is to be expected).  The colors and size were still wrong.

Comment 5

[Eevee (Evelyn Woods) [:eevee]]

Attachment: aurora with the fontconfig workaround

Ah, had to force a rescan, which makes Chromium work perfectly.

Firefox stable and nightly seem unchanged.  Aurora, on the other hand...  well, not sure what's going on here.  Curiously, each character's visible line-height now matches its hover area.

Comment 6

[John Daggett (:jtd)]

(In reply to Eevee (Alex Munroe) [:eevee] from comment #5)
> Created attachment 8614519 [details]
> aurora with the fontconfig workaround
> 
> Ah, had to force a rescan, which makes Chromium work perfectly.
> 
> Firefox stable and nightly seem unchanged.  Aurora, on the other hand... 
> well, not sure what's going on here.  Curiously, each character's visible
> line-height now matches its hover area.

Unchanged means what? You see Symbola used?

Guessing we need to do some work here to get this to work correctly, independent of whether the old gfxPangoFontGroup code is used or not.

Alex, do you see different rendering in nightly if you set 'gfx.font_rendering.fontconfig.fontlist.enabled' to false and restart?

Comment 7

[Eevee (Evelyn Woods) [:eevee]]

Nightly used Symbola, yes.  With that pref set to false, nightly looks the same as aurora -- oversized and recolored to match the font color.

Comment 8

[John Daggett (:jtd)]

(In reply to Eevee (Alex Munroe) [:eevee] from comment #7)
> Nightly used Symbola, yes.  With that pref set to false, nightly looks the
> same as aurora -- oversized and recolored to match the font color.

Ok, so we'll leave this open to fix the oversized text/font color problems. After that's fixed we can decide whether to hack in workaround the fact that older versions of fontconfig treat these fonts as unscalable.

Comment 9

[Jonathan Kew [:jfkthame]]

(In reply to John Daggett (:jtd) from comment #3)
> Chrome ran into the same problem, since they only support scalable fonts.
> The new color fonts *are* scalable but older fontconfig versions view
> scalable == outline. The fontconfig code has been updated to add FC_COLOR
> and make FC_SCALABLE = (FC_OUTLINE || FC_COLOR).

This seems like a total hack! How is a color-bitmap font "scalable" any more than a monochrome bitmap font? "Scalable" normally means a resolution-independent vector/outline format that can be rasterized to any size/resolution required, which is NOT the case for color bitmap fonts.

Comment 10

[John Daggett (:jtd)]

Hmmm, not sure I view this as a hack. The font file provides images for a set of sizes not for a single size in the same way embedded bitmap fonts do. fontconfig already has FC_OUTLINE which indicates a scalable vector format. The alternative is to do some form of (FC_SCALABLE || FC_COLOR) within our own code. But most distros are still shipping with 2.11.1 which doesn't support FC_COLOR.

Comment 11

[Jonathan Kew [:jfkthame]]

(In reply to John Daggett (:jtd) from comment #10)
> Hmmm, not sure I view this as a hack. The font file provides images for a
> set of sizes not for a single size in the same way embedded bitmap fonts do.

"Traditional" monochrome embedded bitmap fonts support multiple sizes, too.[1,2]

Noto Color Emoji may survive scaling to large sizes better than most monochrome embedded-bitmap examples, simply because it includes some pretty big bitmaps, but there's absolutely no difference in the "scalability" provided by the technology being used. Bitmaps are bitmaps, and they come in a selection of fixed sizes determined by the font producer. The bitmaps can, of course, be scaled to other sizes, just like any raster image, but that's not what "scalable" means when referring to font formats.

[1] http://www.microsoft.com/typography/otspec/eblc.htm
[2] http://www.microsoft.com/typography/otspec/ebdt.htm

Comment 12

[Eevee (Evelyn Woods) [:eevee]]

This same argument briefly happened on the Chromium ticket.  :)

Also, note that 2.11.1 is still the most recent stable release of fontconfig.

Comment 13

[Behdad Esfahbod]

(In reply to Jonathan Kew (:jfkthame) from comment #9)
> (In reply to John Daggett (:jtd) from comment #3)
> > Chrome ran into the same problem, since they only support scalable fonts.
> > The new color fonts *are* scalable but older fontconfig versions view
> > scalable == outline. The fontconfig code has been updated to add FC_COLOR
> > and make FC_SCALABLE = (FC_OUTLINE || FC_COLOR).
> 
> This seems like a total hack! How is a color-bitmap font "scalable" any more
> than a monochrome bitmap font?

It's scalable in the sense that it's designed to be scaled.  That is not the case for traditional monochrome bitmap fonts.


> "Scalable" normally means a
> resolution-independent vector/outline format that can be rasterized to any
> size/resolution required, which is NOT the case for color bitmap fonts.

That's FC_OUTLINE.

Comment 14

[John Daggett (:jtd)]

Support Google's color emoji fonts requires the right version of both freetype and fontconfig. We should add code to detect when one or more of these fonts are available and tweak the fallback code to choose those fonts for emoji ranges.

Comment 15

[Eevee (Evelyn Woods) [:eevee]]

Now on Firefox 43, and stable is exactly the same.  For whatever it's worth, I noticed that the glyphs are correct...  if I force the font color to black and then invert the whole page.
https://twitter.com/eevee/status/678752643112501249

Nightly is actually slightly improved — it still refuses to use Noto Color Emoji at all when `gfx.font_rendering.fontconfig.fontlist.enabled` is on, but with it off, I get correctly-sized glyphs reasonably shaded to match the text color!
https://twitter.com/eevee/status/678753613972303872
(They still have bogus extents, though.)

I spy some jagged pixels, too, so for whatever reason they're not being scaled down smoothly.

Comment 16

[Behdad Esfahbod]

Let's continue in bug 1264458.