Able to reproduce the issue on Windows 10 and Mac 10.11.6 using latest canary #56.0.2920.0, but unable to reproduce the same using chrome reported version #54.0.2840.99. 

Bisect Information:
=====================
Good build: 56.0.2887.0  Revision(424315)
Bad Build : 56.0.2888.0  Revision(424625)

Change Log URL: 

https://chromium.googlesource.com/chromium/src/+log/7cbefb314906993b65d272f9ee29be10bf8149c9..38647c2aa7b1c45430bf7ac7c4023c6e59ecd7bf

From the above change log suspecting below change

Review url: https://codereview.chromium.org/2411483002

wfh@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks...!!

I don't know, I just reported the issue. 

Just for update,Still able to reproduce the issue on Win 10.0 using latest chrome version 57.0.2931.0.

Note: As of now latest build #57.0.2935.0 (64 - bit) is not available in Windows

wfh@ Could you please look into this issue.

Thanks!

Just for update,Still able to reproduce the issue on Win 10.0 using latest chrome version 57.0.2956.0.

wfh@ Could you please look into this issue.

Thanks!

Able to reproduce the issue on Mac 10.12.1 using chrome version 57.0.2969.0.

wfh@ Could you please look into this issue.

Thanks,

Just to update, still able to reproduce this issue on win-10 using latest canary #57.0.2976.0.

wfh@ - Gentle Ping...!!

Could you please have a look into this issue.

Thanks...!!

Just to update, still able to reproduce this issue on win-10 using latest canary #57.0.2983.0.

wfh@ - Gentle Ping...!!

Could you please have a look into this issue.

Thanks...!!

Just to update, still able to reproduce this issue on mac 10.12.2 using latest canary #58.0.2989.0.

wfh@ - Gentle Ping...!!

Could you please have a look into this issue.

Thanks...!!

Pdfium-related, not Skia.

npm@ can you take a look and see if you can repro?

win32k lockdown CL in #0 is windows only and cannot affect Mac. The bug is marked Win - this is a very old bug - I'm closing this, re-open a new one for OS X if you feel this is still happening.

The bisect is probably wrong but the issue can still be reproduced, so this shouldn't be closed.

okay based on #9 re labeling as macOS. As said, the CL in #0 can't have changed this since it does nothing on macOS. It likely needs another bisect on macOS.

I can reproduce on latest stable 57.0.2987.133 (64-bit) and using --no-sandbox causes characters to be displayed correctly, so it might be related to win32k lockdown for PDFium.

It seems to be specific to that PDF, I can't reproduce on other PDFs - perhaps it is using custom fonts?

It would make sense if this failed on both macOS and Win (with win32k lockdown) as they effectively share a common backend font enumeration/mapping class, CFX_FolderFontInfo. This is always used on macOS and on Win when GDI is disabled (as in PPAPI win32k lockdown). I guess tsepez@ is probably better placed to try and diagnose the root cause as it's something I didn't directly change inside PDFium when making my patches, just reused existing code to remove dependence on GDI. I guess we probably want to do an actual bisect on PDFium rollups if this used to work at some point.

Just tested of M57 on macOS it is still a problem (the output is the same as on Windows) so I think that confirms in my mind its something to do with the font enumeration and fallback code shared between the two implementations.

pdfium_test on Linux also fails.

The following revision refers to this bug:
  https://pdfium.googlesource.com/pdfium/+/27a0f350ff26ba752eb17a593bbaad17fbbe71d2

commit 27a0f350ff26ba752eb17a593bbaad17fbbe71d2
Author: Nicolas Pena <npm@chromium.org>
Date: Wed Apr 12 19:52:00 2017

Some fixes to the fallback font code.

This CL applies several fixes to the fallback font code.
- PDFium uses -1 to indicate that no glyph index was found, but freetype uses
0. In CPDF_TrueTypeFont, an index of 0 indicates a freetype failure, which
means we should try to find the glyph from a fallback font.
- Improve the fallback glyph calculation by going from original font charcode
to unicode to fallback font charcode.
- Consider the m_ExtGID on Mac when deciding the fallback.

Bug:  chromium:665467 
Change-Id: I2be34983e0d768d9a598043f84edd2d70f033c86
Reviewed-on: https://pdfium-review.googlesource.com/4055
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>

[modify] https://crrev.com/27a0f350ff26ba752eb17a593bbaad17fbbe71d2/core/fpdfapi/font/cpdf_truetypefont.cpp
[modify] https://crrev.com/27a0f350ff26ba752eb17a593bbaad17fbbe71d2/core/fpdfapi/font/cpdf_simplefont.cpp
[modify] https://crrev.com/27a0f350ff26ba752eb17a593bbaad17fbbe71d2/core/fpdfapi/font/cpdf_font.cpp
[modify] https://crrev.com/27a0f350ff26ba752eb17a593bbaad17fbbe71d2/core/fpdfapi/render/cpdf_charposlist.cpp

The following revision refers to this bug:
  https://pdfium.googlesource.com/pdfium/+/dde95d8be9bc2817e34429fc38ee6d89d6d5ab75

commit dde95d8be9bc2817e34429fc38ee6d89d6d5ab75
Author: Nicolas Pena <npm@chromium.org>
Date: Tue May 16 22:02:47 2017

Small fix in CPDF_TrueTypeFont load

The ToUnicode map should not be ignored when it exists. Doing so can cause a
charcode to be assigned an incorrect glyph index, and will result in garbled
text.

Bug:  chromium:665467 
Change-Id: I21c1bf560a0731d974191d4189ea730ef9868334
Reviewed-on: https://pdfium-review.googlesource.com/5512
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>

[add] https://crrev.com/dde95d8be9bc2817e34429fc38ee6d89d6d5ab75/testing/resources/pixel/bug_665467_expected_mac.pdf.0.png
[add] https://crrev.com/dde95d8be9bc2817e34429fc38ee6d89d6d5ab75/testing/resources/pixel/bug_665467.in
[add] https://crrev.com/dde95d8be9bc2817e34429fc38ee6d89d6d5ab75/testing/resources/pixel/bug_665467.pdf
[add] https://crrev.com/dde95d8be9bc2817e34429fc38ee6d89d6d5ab75/testing/resources/pixel/bug_665467_expected.pdf.0.png
[modify] https://crrev.com/dde95d8be9bc2817e34429fc38ee6d89d6d5ab75/core/fpdfapi/font/cpdf_truetypefont.cpp

The following revision refers to this bug:
  https://pdfium.googlesource.com/pdfium/+/b332581e185760597e8f0160011b1e6094634ed8

commit b332581e185760597e8f0160011b1e6094634ed8
Author: Nicolás Peña <npm@chromium.org>
Date: Wed May 17 00:14:57 2017

Revert "Small fix in CPDF_TrueTypeFont load"

This reverts commit dde95d8be9bc2817e34429fc38ee6d89d6d5ab75.

Reason for revert: the test added is flaky

Original change's description:
> Small fix in CPDF_TrueTypeFont load
> 
> The ToUnicode map should not be ignored when it exists. Doing so can cause a
> charcode to be assigned an incorrect glyph index, and will result in garbled
> text.
> 
> Bug:  chromium:665467 
> Change-Id: I21c1bf560a0731d974191d4189ea730ef9868334
> Reviewed-on: https://pdfium-review.googlesource.com/5512
> Reviewed-by: Lei Zhang <thestig@chromium.org>
> Commit-Queue: Nicolás Peña <npm@chromium.org>
> 

TBR=thestig@chromium.org,tsepez@chromium.org,dsinclair@chromium.org,npm@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Bug:  chromium:665467 

Change-Id: I704a34f326d31018061bcfd857fb25f7e4ee4cc2
Reviewed-on: https://pdfium-review.googlesource.com/5493
Reviewed-by: Nicolás Peña <npm@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>

[delete] https://crrev.com/fe91c6c8211cec39f871d9202556e1957bf81983/testing/resources/pixel/bug_665467_expected_mac.pdf.0.png
[delete] https://crrev.com/fe91c6c8211cec39f871d9202556e1957bf81983/testing/resources/pixel/bug_665467.in
[delete] https://crrev.com/fe91c6c8211cec39f871d9202556e1957bf81983/testing/resources/pixel/bug_665467.pdf
[delete] https://crrev.com/fe91c6c8211cec39f871d9202556e1957bf81983/testing/resources/pixel/bug_665467_expected.pdf.0.png
[modify] https://crrev.com/b332581e185760597e8f0160011b1e6094634ed8/core/fpdfapi/font/cpdf_truetypefont.cpp

The following revision refers to this bug:
  https://pdfium.googlesource.com/pdfium/+/17f4e0268b31f2f75a01567b83dbb763680344e1

commit 17f4e0268b31f2f75a01567b83dbb763680344e1
Author: Nicolas Pena <npm@chromium.org>
Date: Wed May 17 19:08:33 2017

Reland: Small fix in CPDF_TrueTypeFont load

The ToUnicode map should not be ignored when it exists. Doing so can cause a
charcode to be assigned an incorrect glyph index, and will result in garbled
text.

Previously, some bots failed with 'unable to open' the .png file.

Bug:  chromium:665467 
Change-Id: I435a73647eadcc3ba37bb0120f3b5cee381ae7a3
Reviewed-on: https://pdfium-review.googlesource.com/5610
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>

[add] https://crrev.com/17f4e0268b31f2f75a01567b83dbb763680344e1/testing/resources/pixel/bug_665467_expected_mac.pdf.0.png
[add] https://crrev.com/17f4e0268b31f2f75a01567b83dbb763680344e1/testing/resources/pixel/bug_665467.in
[add] https://crrev.com/17f4e0268b31f2f75a01567b83dbb763680344e1/testing/resources/pixel/bug_665467_expected.pdf.0.png
[modify] https://crrev.com/17f4e0268b31f2f75a01567b83dbb763680344e1/core/fpdfapi/font/cpdf_truetypefont.cpp

 Issue 850423  has been merged into this issue.