860142 - emoji doesn't honor color: transparent on Mac OS X

Status: NEW

(Firefox :: PDF Viewer, defect, P3)

Description

[John Daggett (:jtd)]

Attachment: screenshot, emoji sample page in pdf.js

The Unicode code page pdf for emoji doesn't display correctly, under OSX it displays a bunch of color emoji characters, I'm guessing fallback is occuring.  Both OSX Preview.app and Safari/Chrome display the pdf correctly, without the use of color emoji.

Note: I tested with the latest dev version of pdf.js from github.

Comment 1

[Masatoshi Kimura [:emk]]

Does this link work?
http://www.unicode.org/charts/PDF/U1F300.pdf#textLayer=off

Comment 2

[Jonathan Kew [:jfkthame]]

Yes, with textLayer=off it looks OK (without checking in detail).

It seems like the embedded font must be loading successfully, otherwise it wouldn't be able to draw the glyphs on the canvas; but then why does it fall back to Apple Color Emoji in the text layer? Strange...

Comment 3

[Brendan Dahl [:bdahl]]

The textlayer should be invisible no matter what. It seems on windows things work as expected, but on OSX the emoji text is visible.

I say we should re-file this issue since it seems it's not really an issue with pdf.js.

Comment 4

[Masatoshi Kimura [:emk]]

Obviously emoji will not honor other color values. Should "transparent" be special?

Comment 5

[John Daggett (:jtd)]

(In reply to Brendan Dahl from comment #3)
> The textlayer should be invisible no matter what. It seems on windows things
> work as expected, but on OSX the emoji text is visible.
> 
> I say we should re-file this issue since it seems it's not really an issue
> with pdf.js.

I don't think I see what the issue here would be in Graphics:Text, differences in textlayer rendering are a pdf.js issue, no?  Differences in Windows vs. OSX I think are most likely related to font availability.  I think the comparison is what pdf.js produces vs. what Preview.app or Safari displays - both of those do not show the color emoji.

Comment 6

[Masatoshi Kimura [:emk]]

(In reply to John Daggett (:jtd) from comment #5)
> I don't think I see what the issue here would be in Graphics:Text,
> differences in textlayer rendering are a pdf.js issue, no?  Differences in
> Windows vs. OSX I think are most likely related to font availability.

Even if emoji font is present on Windows (for example on Windows 8), it will honor "color: transparent" because Windows doesn't support multiple color glyph.

> I think the comparison is what pdf.js produces vs. what Preview.app or Safari
> displays - both of those do not show the color emoji.

pdf.js tries to produce what Preview.app does, but it is prevented by the renderer's bug (or feature).

Comment 7

[Masatoshi Kimura [:emk]]

Attachment: Minimized testcase

This patch doesn't have to do with PDF at all.
What is the expected result?
If emoji glyphs should be transparent, this is a Core/Graphics bug. If emoji glyphs should ignore "transparent" just like all other colors, we need to find other workarounds and I'll change back the component to Firefox/PDF.js.

Comment 8

[Masatoshi Kimura [:emk]]

> This patch
Of course, this testcase.

Comment 9

[Masatoshi Kimura [:emk]]

Some other questions:
1. What about rgba() and hsla() colors?
2. How Safari behaves?

Comment 10

[Jonathan Kew [:jfkthame]]

The testcase shows that Safari also ignores the color property on the Apple Color Emoji text. I think that's pretty reasonable, actually.

That presumably means that pdf.js would have the same problem displaying the emoji code chart in Safari, too (untested).

Maybe pdf.js could use opacity:0 to make the text layer invisible, instead of setting the color?

Comment 11

[Masatoshi Kimura [:emk]]

(In reply to Jonathan Kew (:jfkthame) from comment #10)
> Maybe pdf.js could use opacity:0 to make the text layer invisible, instead
> of setting the color?

Unfortunately it made the selection invisible :(

Comment 12

[Masatoshi Kimura [:emk]]

Changing back the component because it looks like the color property should be ignored on emoji glyphs.

Comment 13

[Jonathan Kew [:jfkthame]]

(In reply to Masatoshi Kimura [:emk] from comment #11)
> (In reply to Jonathan Kew (:jfkthame) from comment #10)
> > Maybe pdf.js could use opacity:0 to make the text layer invisible, instead
> > of setting the color?
> 
> Unfortunately it made the selection invisible :(

Hm, yes, that makes it rather less useful.

I suppose the real question is why pdf.js isn't using the "real" font for the text layer, like it does for drawing to the canvas. If it did that, there wouldn't be a problem with fallback finding the color emoji font and becoming visible.

Comment 14

[Masatoshi Kimura [:emk]]

Currently PDF.js doesn't support non-BMP characters when rendering to canvas. So all non-BMP characters will be replaced with PUA code points. (And PDF.js will modify the embedded font accordingly.)
On the other hand, for the selection purpose, PDF.js uses non-BMP code points as-is because they may be pasted into other apps.

Comment 15

[Yury Delendik (:yury)]

(In reply to Masatoshi Kimura [:emk] from comment #12)
> Changing back the component because it looks like the color property should
> be ignored on emoji glyphs.

I don't see how minimized testcase is related to PDF Viewer component

Comment 16

[Jonathan Kew [:jfkthame]]

It simply demonstrates that color:transparent (or any other color, AFAIK) is ignored when the color emoji font is used; the glyphs retain their inherent color.

And therefore, if the PDF viewer is going to allow font fallback to happen in the text layer (rather than explicitly using the "correct" font from the PDF), it cannot rely on color:transparent to make the text invisible.