You can see this on this web page:

http://www.alanwood.net/demos/wingdings.html

The Windgings Character column SHOULD MATCH what's in the Unicode Character (it does in IE), but Beta and Dev Chrome no longer match.

Interesting. For some reason we fail to load wingdings in beta.

Behdad@, kojii@, could this be a symbol CMAP format issue?

Yes, this is a regression from hb-ot-font switch in  bug 589340 . The page renders correctly on IE and on Chrome stable, but not on beta/dev nor on Firefox, as observed in comment #15 of  bug 589340 .

We probably don't want to revert it do we? Any chance for HB to support symbol CMAP?

Behdad, any chance this could be brought into HarfBuzz with a short timeline? Or do we need to implement a fallback callback based on CMAP table format? Thanks very much in advance if you plan to add it.

It's straightforward.  I have had wanted to do it.  Will send a patch this week.

Great, thanks!

Here:
https://github.com/behdad/harfbuzz/commit/34f9aa582c3a03b578c7eae3d2e8860a0bd5cb00

Fixed by rolling HarfBuzz to 1.3.0, tracked in  issue 630275 . 

Layout test upcoming in https://codereview.chromium.org/2183023003

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b550f7d3b713058b9a719fdfd79cd863638d6327

commit b550f7d3b713058b9a719fdfd79cd863638d6327
Author: drott <drott@chromium.org>
Date: Tue Jul 26 14:53:44 2016

Add a Windows layout test for validating symbol CMAP encoding support

In version 1.3.0 HarfBuzz adds support [1] for symbol encoding
CMAP tables (platform ID = 3, encoding ID = 0, glyphs offset by
0xF000), for which support in Blink regressed when we moved to
the OpenType functions from HarfBuzz. This layout test adds a
custom SymbolCMAPTest font which uses the Microsoft specific
symbol CMAP encoding. It also adds a reference font which has the
same glyph for comparison at Private Use area codepoint 0xE000.

The test font's CMAP table for platformID="3" looks as follows,
when dumped using ttx:

    <cmap_format_4 platformID="3" platEncID="0" language="0">
      <map code="0xf020" name="space"/>
      <map code="0xf041" name="A"/>
    </cmap_format_4>

So, it was verified to follow the Symbol CMAP encoding pattern.

[1] https://github.com/behdad/harfbuzz/commit/34f9aa582c3a03b578c7eae3d2e8860a0bd5cb00

BUG= 627953 
R=behdad,kojii,eae

Review-Url: https://codereview.chromium.org/2183023003
Cr-Commit-Position: refs/heads/master@{#407794}

[modify] https://crrev.com/b550f7d3b713058b9a719fdfd79cd863638d6327/third_party/WebKit/LayoutTests/NeverFixTests
[add] https://crrev.com/b550f7d3b713058b9a719fdfd79cd863638d6327/third_party/WebKit/LayoutTests/fast/text/resources/SymbolCMAPTest.ttf
[add] https://crrev.com/b550f7d3b713058b9a719fdfd79cd863638d6327/third_party/WebKit/LayoutTests/fast/text/resources/SymbolCMAPTestRef.ttf
[add] https://crrev.com/b550f7d3b713058b9a719fdfd79cd863638d6327/third_party/WebKit/LayoutTests/fast/text/symbol-cmap-expected.html
[add] https://crrev.com/b550f7d3b713058b9a719fdfd79cd863638d6327/third_party/WebKit/LayoutTests/fast/text/symbol-cmap.html

This is something that is affecting Quickoffice Chrome. 

According to this thread: https://productforums.google.com/forum/#!topic/chrome/zlvlLoZum6Q this bug started appearing in Chrome 52 and has been fixed in Chrome 55. Should this be cherry picked into Chrome 53/54? Otherwise it will be broken for a long period of time - until Chrome 55 gets into Chrome Stable channel?

+govind@chromium.org, bustamante@chromium.org to evaluate merge question in c#14

Please request a merge to M53 and M54 by adding "Merge-Request-53" and "Merge-Request-54" labels.

We already cut M53 Stable RC for this week release. We can take this change in for next M53 stable release if any in future (hopefully by then it will be baked in M54 beta too)

bustamante@ for M54 merge review and approval.

[Automated comment] Commit may have occurred before M54 branch point (8/25/2016), needs manual review.

It's unfortunate that this regression occurred but I am somewhat hesitant to backport https://crrev.com/e58743c4354ba98a29907e630d616da3053ccf53 to M53, the stable branch because it's not an isolated commit fixing symbol fonts, but a version roll of HarfBuzz. 

M54 already has HarfBuzz 1.3.0 which has the fix, compare 
https://chromium.googlesource.com/chromium/src/+/54.0.2840.25/third_party/harfbuzz-ng/README.chromium

Yeah it looks like HarfBuzz is already on 1.3.0 and the layout tests from #13 are present in the 2840 branch.

Removing Merge-Review-54 Hotlist-Merge-Review labels.  If there was a different change that needed to be merged, add the label back and I'll review again.