http://www.coder.or.jp/hdr/19/HDRVol19.12.pdf
is another example, where Google Chrome 52 shows garbled texts.

http://www.saga-ed.jp/kenkyu/kenkyu_chousa/h22/02_chu_kokugo/documents/model2.pdf
http://kurarika.net/theme130318.pdf
http://www.torii.co.jp/health/lifescience/pdf/41_2.pdf

are also samples that show this bug.
In Google 51 there was no problem for these PDFs.

Able to reproduce the issue on Chrome Beta# 52.0.2743.24 and Chrome Dev# 53.0.2756.0 on Windows.
This is a Regression issue in M52, below is the info,
Chrome Good Build: 52.0.2738.0
Chrome Bad  Build: 52.0.2739.0
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/b63b54ffb934677bcb8b6986a250bea71c0d147e..8eb4c80b7558a1bdd547e24b6b129b0d84223b21

Suspecting Commint# 08e9434b6f4938517755815da37752b0cd906be7
Suspecting Review URL# https://codereview.chromium.org/1950123002
@dsinclair -- Could you plese look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Note: The pdf is seen without any garbage text on Mac and Linux.

Thank You.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This renders correctly if XFA is turned off but fails when enabled.

Removing the milestone because XFA has been disabled.

May I add your example PDF to our corpus of test files?

Fix out for review: https://codereview.chromium.org/2097523002/.

It looks like the issue is, when XFA is enabled, we don't load up the font maps, so when we lookup the characters to get the glyphs to display we decide the font is not unicode and just return the character. We then display the incorrect glyph. Loading the font maps fixes the issue.