Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 62435 Emoji does not display in webpage contents on OS X Lion+
Starred by 1009 users Reported by, Nov 9 2010 Back to list

Comments by non-members will not trigger notification emails to users who starred this issue.
Status: Fixed
Closed: Dec 2014
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment
Chrome Version       : 7.0.517.41
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: FAIL
  Firefox 3.x: OK
       IE 7/8: n/a

What steps will reproduce the problem?
1. Install Symbola font from (or any other font which includes the Emoji symbol for U+1F4A9)
2. View test page at

What is the expected result?
All four boxes should display the same pile of poo.

What happens instead?
On Kubuntu Linux 10.10 with stable Chrome release, the three Unicode character versions display correctly and are identical to the "Should look like" image.
On Mac OS X, the three Unicode character versions do not display; instead, I get the empty box character.

Please provide any additional information below. Attach a screenshot if

This is probably a much more general problem, but that's the Unicode character I noticed it with...
Comment 1 Deleted
Comment 2 Deleted
Comment 3 Deleted
Comment 4 Deleted
Comment 5 Deleted
Comment 6 Deleted
Comment 7 Deleted
Comment 8 Deleted
Comment 9 Deleted
Comment 10 Deleted
Comment 11 Deleted
Comment 12 Deleted
Comment 13 by, Oct 28 2011
Labels: Hotlist-MacOSXLion
Summary: Emoji does not display in webpage contents on OS X Lion (was: NULL)
was: Unicode / font-fallback: Unicode pile of poo does not display on Mac OS X, works on Linux
Comment 14 Deleted
Comment 15 Deleted
Comment 16 by, Oct 28 2011
Thakis commented on bug 90177:

Happened to see this in WebKit/Tools/DumpRenderTree/mac/DumpRenderTree.cpp:

   [preferences setPictographFontFamily:@"Apple Color Emoji"];

Maybe related?
Although it's not a great idea to invent a new CSS generic family for emoji (imho), that's what's done. So, I believe by adding a new preference for PictorGraphFontFamily, we can fix this problem. I'll give it a shot as I mentioned in bug 90177. 

The webkit change for PictorGraphFontFamily is

The change will only work on Lion. We need to do some plumbing in Chrome and chrome's webkit.  

Comment 19 Deleted
Comment 20 Deleted
Comment 21 Deleted

The above page contains the full set of Emoji added to Unicode 6. The 2nd column uses the code points for some 720 Emoji characters.
On Mac OS Lion, there is Apple Color Emoji that can display all the Emoji on Safari. Unfortunately none of the Emoji displays on the latest Chrome.
Can we make sure that Chrome too displays all the characters on Mac using Mac OS Lion's built in font for Emoji? 
Comment 23 Deleted
(+cc some WebKit fonts / i18n folks)
Probably needs

but that's not enough. (A html file that contains "
suggest that the emoji font is special; maybe the font serialization can't handle it?
To support Apple Color Emoji, we need to ask Skia people to use CTFontDrawGlyphs(), which available in 10.7 SDK. WebKit mac port uses the API.

I gave that a try, but failed to get it to work so far. Work in progress attached.
2.1 KB View Download
Stuff looks almost correct if I set the offset to {0,0}; I suppose coretext transformation order is slightly different.
Comment 30 Deleted
Issue 150599 has been merged into this issue.
Comment 32 by, Sep 20 2012
Issue 150748 has been merged into this issue.
In addition to the changes mentioned above, needs to be reverted too.
A few notes about SkFontHost_mac_coretext.cpp:

* SkFontHost::FilterRec needs to always use kLCD16_Format for bitmap fonts such as emoji, else it might create grayscale glyphs and emoji characters show up as greyscale. (attached patch has proof-of-concept code for this)

* On retina displays, bitmap fonts are currently rendered at half the resolution

* Gamma correction (or something) causes colors for bitmap fonts to be off. Skip doing this for bitmap fonts.

* Text is currently drawn white-on-black with a TODO to invert this. This is apparently needed for bitmap fonts, else they end up with inverted colors. (Or something further down in skia inverts, so a double-invert is needed to make that a noop). Also proof-of-concepted in the attached patch.
7.5 KB View Download
Comment 35 Deleted
Summary: Emoji does not display in webpage contents on OS X Lion+ (was: NULL)
(See issue 151883 for the omnibox shift caused by emojis)
LayoutTests/fast/css/font-family-pictograph.html starts looking ok when forcing rec->fMaskFormat to kLCD32_Format (not kARGB32_Format surprinsingly) in SkFontHost::FilterRec(), and when sending SkScalerContext_Mac() down the leopard path always (which passes the true font size instead of 1 for the font size).

(Note: it's still pixel-scaled on retina.)
Project Member Comment 40 by, Oct 5 2012
The following revision refers to this bug:

r160338 | | 2012-10-05T08:56:03.686369Z

Changed paths:

mac: Plumbing for the emoji font.

Since emoji is disabled in webkit for chromium, this has no observable effect yet.

BUG= 62435 

Review URL:
After the above commit, the following changes are needed to get the proof-of-concept going:

1. Revert  in webkit (just 2 lines) locally
2. Apply the patch from comment 34

Issues with the patch:
* Emojis show up as lodpi on retina displays
* Baselines are messed up (bashi suggests this could be fixed by using the emoji font only for bitmap font glyphs)
* The skia patch is very messy

bashi says he'll try to get the skia part moving.
I added a couple of comments to (post-commit comment). They're just about font pref on Windows and Linux. 

Project Member Comment 43 by, Oct 16 2012
The following revision refers to this bug:

r162045 | | 2012-10-16T02:11:47.859944Z

Changed paths:

Address review feedback for r160338

On Windows, use Segoe UI Symbol as emoji font.
On CrOS, use Droid Emoji.
Simplify the defaults, they're overridden anyway.

BUG= 62435 

Review URL:
Comment 44 Deleted
Comment 45 by, Nov 14 2012
Emoji is shown correctly in Title (or when adding a bookmark).

Emoji is not correct when it's in the content.


Version 25.0.1323.1 dev
Comment 46 by, Feb 24 2013
What needs to happen to get this to work? Note: The standard OSX Japanese IME inserts emoji 

type 'ichigo' you get not 苺 only but also 
gman: See comment 41 and some of the previous comments. The most important thing is to figure out how to do the skia parts right (need to call the new CTFontDrawGlyphs() function and tell skia to use 32 bit glyphs; comment 41 has a somewhat-working patch).
Comment 48 by, Mar 8 2013
I tried to put some 
Comment 49 Deleted
Comment 50 Deleted
Comment 51 Deleted
Comment 52 Deleted
The same thing is happening in Chrome on Windows 8 (which has native support for emoji). Internet Explorer displays them correctly, but Chrome up till today doesn't...perhaps cause fkn Google doesn't support emoji in any of its OS, so it wants other OS users to see the web the same way its OS users do.
Comment 54 by, Apr 30 2013
Issue 236171 has been merged into this issue.
Comment 55 Deleted
You can install this Chrome extension for emoji in the meantime:
Comment 57 Deleted
Comment 58 by, Jul 20 2013
What's required to resolve this issue and properly support emoji? Also, what's the status on Windows and ChromeOS? Emoji seem to be showing up properly for me on ChOS.
brian: See previous comments for what needs to be done. Summary:

1. Skia needs to be learn to draw 32bit rgba glyphs
2. Skia's mac text renderer needs to call CTFontDrawGlyphs() for bitmap fonts (see patch in comment 34)
(2b. Make sure they show up hidpi on retina displays)
3. Some minor plumbing needs to be done to enable this in skia (see comment 41)

CrOS uses vector fonts for Emoji and hence uses the regular font rendering paths for them. Apple decided that Emojis warrant introducing 32bit rgba bitmap fonts (which means they look bad at very large font sizes, but that's admittedly a rare use case), and skia doesn't support that new font mode yet.

I saw a design doc from reed@ about 32bit bitmap glyphs a while ago, I don't know what the status of that is.
Comment 60 Deleted
Comment 61 Deleted
Issue 273491 has been merged into this issue.
Comment 63 by, Sep 28 2013
JFYI : See bug 245397. Skia on Linux/Android can handle color glyphs with FreeType Android WebView support was added, which can be ported to Blink on Linux. 
Comment 64 Deleted
Comment 65 Deleted
Comment 66 Deleted
Comment 67 Deleted
Comment 68 Deleted
Comment 69 Deleted
Comment 70 by, Dec 18 2013
Win8.1/IE11 equivalent to this bug: Issue 333011
Comment 72 by, Jan 10 2014
Labels: Restrict-View-EditIssue
Please star the issue to indicate that you'd like to see it fixed, adding redundant comment only slows down the process.
Comment 73 by, Jan 10 2014
Labels: -Restrict-View-EditIssue Restrict-AddIssueComment-EditIssue
Ran into this again today, came to check on things and see if I could help fix.  I see a plan laid out in comment 59, but that's almost 8 months ago and I know the font code has changed significantly since!  Curious if either Email or Ben have a status update as to what remains and if there are ways others can help with the remaining issues.  Thanks!
Comment 75 by, Feb 9 2014
I'm slowly working on a fix, but it isn't very promising at the moment. I tried applying Nico's patch and cleaning up the Skia code, but his patch doesn't work anymore. :(
I spoke to Ben, and he mentioned he has looked a bit at it and had a sketch of patch, but he's been pretty busy with the Windows font stuff so I haven't got ahold of it yet. In any case, I was going to ask some Skia folks next week if they could point me in the right direction towards fixing this. 
Any and all comments welcome!
Comment 76 by, Mar 3 2014
Here is the patch that I currently have, based on Nico's old patch. I'm building with the 10.7 sdk, so I temporarily took out the dlsym call to make sure that isn't what is breaking everything (it isn't). This code is currently drawing the glyphs with CTFontDrawGlyphs, which I understand is the right approach. 

The problem is that even though the baselines seem fine for the text, I've never been able to actually see an emoji glyph being drawn. The glyph bounds are fine (if I memset the background to green, I see the proper square where the emoji should be), and the loaded font has color glyphs, but they do not show up.
5.3 KB Download
Mostly works for me. left to right: chrome, chromium with your patch, safari. (Colors are off, but hey.)

This is on 10.8, non-retina. Maybe it's not right on retina displays yet.

I did:

cd third_party/skia/src; patch -p1 < ~/Downloads/emoji.patch
cd -
cd third_party/WebKit
# change stuff
git diff
diff --git a/Source/platform/fonts/mac/ b/Source/platform/fonts/mac/
index a67362d..7cba3b3 100644
--- a/Source/platform/fonts/mac/
+++ b/Source/platform/fonts/mac/
@@ -119,8 +119,8 @@ PassRefPtr<SimpleFontData> FontCache::platformFallbackForCharacter(const FontDes
         return nullptr;
     // Chromium can't render AppleColorEmoji.
-    if ([[substituteFont familyName] isEqual:@"Apple Color Emoji"])
-        return nullptr;
+    //if ([[substituteFont familyName] isEqual:@"Apple Color Emoji"])
+        //return nullptr;
     // Use the family name from the AppKit-supplied substitute font, requesting the
     // traits, weight, and size we want. One way this does better than the original
Screen Shot 2014-03-04 at 11.40.02 AM.png
793 KB View Download
On 10.9, the patch doesn't work for me either, independent of retinaness.

(This is how Firefox added support:
Comment 79 Deleted
Comment 80 Deleted
Comment 81 Deleted
Comment 82 Deleted
Comment 83 Deleted
Comment 84 Deleted
Comment 85 Deleted
Comment 86 Deleted
Issue 361986 has been merged into this issue.
Here's a silly demo that shows that CTFontDrawGlyphs does the thing on 10.9, so the patch probably just has a few offsets off? Here's a screenshot of running this on 10.9, would be interesting to see if this has the same output on 10.8.
Screen Shot 2014-05-18 at 10.23.56 PM.png
100 KB View Download
1.1 KB Download
FooView.m only shows a red rectangle on 10.8.
Comment 91 by, Jun 6 2014
Given how consistently this patch works, I can't wait to try it out on 10.10 :(
The patch works on 10.10!
Comment 93 by, Aug 14 2014
Great to hear that it works on 10.10. 
If it works on 10.10 (but not in earlier OS X), I think we should get this in potentially with a run-time OS version check to avoid a problem on earlier OS X (if any). 

I'm afraid we're getting a lot of bad PR on this issue. 
Comment 94 by, Aug 14 2014
It will still be interesting to know how come it worked on 10.8 and 10.10 but not 10.9, and last time I checked the patch is still missing polishing from Skia side to fully work. Any chance to get more Skia developers to help understanding it better? I have tried but without more Skia background it's hard to understand how it is supposed to work.
Comment 95 by, Aug 14 2014
I think rsesek@ was referring to Nico's red square patch. I dont think the emoji patch works on 10.10, or is in any shape ready to go out.

Right, I was testing Nico's FooView.m, which does not work on 10.8, but it does on 10.9 and 10.10. I definitely support just getting this done for modern OSes using a run-time check. We've been without emoji support for far too long.
Comment 97 by, Sep 2 2014
I'll sync-up with bungeman tomorrow, and see if he has any insight.
Comment 98 by, Sep 2 2014
Comment 99 by, Sep 16 2014
Issue 414535 has been merged into this issue.
Issue 395049 has been merged into this issue.
Comment 101 by, Oct 29 2014
@reed, what was the result of your September 3 meeting with bungeman? (re: comment #97)
Skia doesn't support Mac's color emoji at the moment, but currently Blink also doesn't fall back to the emoji font to make the request, so Skia's lack of support isn't even being hit (which is why Skia hasn't seen any requests). The priority over the last year has been DirectWrite and Android, but I'll be getting to this soon.
bungeman: See comment 41 on how to let blink call through to skia (it's a 2-line thing.)
Comment 104 by, Nov 18 2014
Labels: M-41
Comment 105 by, Nov 18 2014
Status: Assigned
I hope bungeman@ wouldn't mind the status being changed to assigned (this bug even has M-41 target) and it'll be really great to see some movement on the Skia-side. 

BTW, the following Guardian article has the subtitle, "just don’t expect to laugh at this piece if you use Chrome; use Firefox instead".
Comment 107 by, Dec 1 2014
With Skia after be2284de556e7ec29489693093d42dc86b762645, works for me for OS X 10.7+. Still need to resolve the symbols for 10.6 support (and remove the two lines blocking Apple Color Emoji in Blink), of course.
@jiangi : great.  thanks.  Would you make a CL with necessary additional changes mentioned in your comment?  

@bungeman : Is the Skia-side done or do you expect to make any more change for color font support (Apple's color font) on Mac OS X? 
Comment 109 by, Dec 4 2014
@jshin, this is more like a proof of concept patch so might not be optimal to use, I have uploaded to anyway so that Ben can take a look.
Comment 110 by, Dec 4 2014
(Blink side of changes has to be submitted separately in Blink repo though.)
Project Member Comment 112 by, Dec 11 2014
The following revision refers to this bug:

r186981 | | 2014-12-11T20:50:47.066473Z

Changed paths:

Auto-rebaseline for r186973

BUG= 62435

Review URL:
Project Member Comment 113 by, Dec 12 2014
The following revision refers to this bug:

r186991 | | 2014-12-11T23:56:46.919700Z

Changed paths:

[Mac] Chromium can now handle Apple Color Emoji

This removes the block on this specific font name.
Sbix fonts on Mac should now be handled correctly.

BUG= 62435 

Review URL:
Project Member Comment 114 by, Dec 12 2014
The following revision refers to this bug:

r186993 | | 2014-12-12T02:21:32.331274Z

Changed paths:

Auto-rebaseline for r186991

BUG= 62435

Review URL:
Status: Fixed
Seems to work now. Thanks!
Screen Shot 2014-12-12 at 11.24.36 AM.png
240 KB View Download
Attempting to remove from cc.
Sign in to add a comment