1063622 - On a Mac, Firefox produces garbage for certain emoji characters.

Status: RESOLVED DUPLICATE of bug 923007

(Core :: Graphics: Text, defect)

Description

[Mark]

Attachment: Screenshot of expected results (Safari)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.24 Safari/537.36

Steps to reproduce:

On a Mac
Open up http://絵文字-

Comment 1

[Mark]

Attachment: Screenshot of actual results (Firefox)

Comment 2

[Jonathan Kew [:jfkthame]]

Mark, unfortunately this version of bugzilla doesn't allow entry of SMP characters - the MySQL version in use is too old :(. Hence, your URL in comment 0 is truncated. Could you please provide it in %-escaped UTF-8 or punycode form?


(An aside: I tried looking for a link via http://unicode-inc.blogspot.co.uk/2014/09/iuc-38-keynote-presenter-announced.html, but didn't find it there. However, I noticed an emoji issue on that page too; try hovering over the image of the title to see its tooltip. In this case there's an authoring problem: the page source has

  <img alt="絵文字 : &#55356;&#57328;, &#55356;&#57217;, and &#55357;&#56960; = Emoji: Past, Present, and Future" src="http://www.unicode.org/announcements/Emoji-Keynote-306x37.png" height="37" style="border-width: 0px;" title="絵文字 : &#55356;&#57328;, &#55356;&#57217;, and &#55357;&#56960; = Emoji: Past, Present, and Future" width="306" /></a>

which encodes the emoji characters as separate character entities for their high and low surrogates. When using entities, they should instead be encoded directly as their SMP codepoints.)

Comment 3

[Masatoshi Kimura [:emk]]

I took the URL from the screenshot.
http://xn-------tj3b5125au5ohf9bds16cx5aj4q.blogspot.com/2014/09/this-is-test-blog-with-emoji-in-domain.

Comment 4

[Jonathan Kew [:jfkthame]]

I'm pretty sure this is triggered by the use of the emoji-style variation selector to force emoji representation of the HOT BEVERAGE symbol, which is in one of the BMP symbol blocks rather than the main emoji block:

<h1 class='title'>
絵文字-&#9749;&#65039;
</h1>

Without the &#65039;, it would likely render the b/w glyph from a font such as Menlo.

If you explicitly choose the Apple Color Emoji font, it'd probably render the color glyph as expected; e.g. by wrapping it in a <span style="font-family:Apple Color Emoji">...</span>.

The problem arises (I believe) because the presence of the variation selector is causing Core Text to do an internal font switch during glyph generation, but Gecko is unaware of this and so renders the resulting glyph IDs from the wrong font.

(I thought we already had a bug report on this, but can't find it offhand.)

Comment 5

[Jonathan Kew [:jfkthame]]

Ah, see bug 923007. I suspect this is the same issue.

Comment 6

[Mark]

(In reply to Jonathan Kew (:jfkthame) from comment #2)
> Mark, unfortunately this version of bugzilla doesn't allow entry of SMP
> characters - the MySQL version in use is too old :(. Hence, your URL in
> comment 0 is truncated. Could you please provide it in %-escaped UTF-8 or
> punycode form?
> 
> 
> (An aside: I tried looking for a link via
> http://unicode-inc.blogspot.co.uk/2014/09/iuc-38-keynote-presenter-announced.
> html, but didn't find it there. However, I noticed an emoji issue on that
> page too; try hovering over the image of the title to see its tooltip. In
> this case there's an authoring problem: the page source has
> 
>   <img alt="絵文字 : &#55356;&#57328;, &#55356;&#57217;, and &#55357;&#56960; =
> Emoji: Past, Present, and Future"
> src="http://www.unicode.org/announcements/Emoji-Keynote-306x37.png"
> height="37" style="border-width: 0px;" title="絵文字 : &#55356;&#57328;,
> &#55356;&#57217;, and &#55357;&#56960; = Emoji: Past, Present, and Future"
> width="306" /></a>
> 
> which encodes the emoji characters as separate character entities for their
> high and low surrogates. When using entities, they should instead be encoded
> directly as their SMP codepoints.)

That's blogspot's doing... I'll file a bug for that.

Comment 7

[Jonathan Kew [:jfkthame]]

Closing this as a duplicate of bug 923007, as I believe it's the same problem as described there. Mark, I've just posted an experimental build with a patch that may help to avoid the garbage rendering here; see bug 923007 comment 15. If you could test that build and let me know the result, I'd appreciate it - thanks.

Comment 8

[Mark]

Thanks, that was fast!

Sorry, I can't test it for you because the Mac is my work machine, and I can't download arbitrary images. I hope someone else can test it.