Unable to reproduce the issue on Win-7 and Win-10 using chrome reported version #64.0.3282.71 and latest chrome version #65.0.3315.0.

Attached a screen shot for reference.

Following are the steps followed to reproduce the issue.
------------
1. Opened http://ncu.rcnpv.com.tw/Uploads/20131231103232738561744.pdf
2. Observed that PDF correctly displayed as foxitReader as expected.

baudav@ - Could you please check the issue on latest chrome version #65.0.3315.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

Deleted: 799699.PNG 190 KB

	799699.PNG 190 KB View Download

I not reproduce in W8.1
tested with canary (new install). I reproduce.
tested with beta with new profile. I reproduce.
tested with beta and new windows session. I reproduce

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

So this only happens on Windows 7, correct? Is this an English edition of Windows 7 or some other language? Can you also install Stable Channel (Chrome 63) and see if that reproduces the issue as well?

In a random Windows 7 VM I have laying around, the fonts are simply not there. Rather than being superimposed.

The weird thing about bisecting is that once I hit a "good" build, the issue no longer reproduces with a "bad" build. I have to reboot to get the "bad" build to behave badly again. This smells like a font caching bug from r519471.

+rockot for more eyes on the bug. I looked at the CL but nothing stood out.

FTR, I bisected down to r519468 good / r519491 bad.

Happy to help test fixes, BTW.

One more note: Any deviation from the correct rendering should be considered bad. With a different PDF, sometimes that PDF rendered 95% correct and the difference was subtle.

It does sound suspiciously like font caching. Could it be that the RegisterCommonBrowserInterfaces call is being missed? Or happening too late to be used for PDF rendering?

For what thestig@ reproduced, I believe crrev.com/c/866110 should fix it. I am not sure OP's problem is the same, but we can try after that CL lands.

Seems like this CL(https://chromium-review.googlesource.com/c/chromium/src/+/866110) has been landed 2 days ago. Could someone please request M64 merge if it looks good on Canary?

Thank you!

I haven't gotten around to verifying it looks good on Canary.

Fixed by r525716 with the font_cache entry here: https://chromium.googlesource.com/chromium/src/+/8039712928cd2724f28cf42019ce16202db3505d%5E%21/#F5

Maybe just cherrypick that one bit of change to M64?

That's not my change. Can we reassign to someone else?

rockot@ - can you please confirm if change in #11 should be merge to M64 and if it has been verified to fix the issue?

We should cherry-pick the union of #11 and the relevant parts of #14. Happy to do it if we have approval.

This bug requires manual review: We are only 0 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

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

Thanks rockot@ - is this fairly safe overall? No chances of introducing new regressions? Change seems fairly small. 

No chance of new regressions.

approved - branch:3282

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

commit f0f7913978dc12fa769ec77b23ea980979b1d679
Author: Ken Rockot <rockot@chromium.org>
Date: Tue Jan 23 00:31:56 2018

Cherry-pick fix for font cache access in subprocesses

This is a selective combination of bits from two CLs[1][2],
enabling utility and plugin processes to have access to the
browser's content::mojom::FontCacheWin interface.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/815995
[2] https://chromium-review.googlesource.com/c/chromium/src/+/866110

Bug:  799699 
Change-Id: I2bd97d35ce3a8ae1034c3b7c281a52fb4fbdc90e
Reviewed-on: https://chromium-review.googlesource.com/879534
Reviewed-by: Ken Rockot <rockot@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#577}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/f0f7913978dc12fa769ec77b23ea980979b1d679/content/public/app/mojo/content_browser_manifest.json
[modify] https://crrev.com/f0f7913978dc12fa769ec77b23ea980979b1d679/content/public/app/mojo/content_plugin_manifest.json
[modify] https://crrev.com/f0f7913978dc12fa769ec77b23ea980979b1d679/content/public/app/mojo/content_utility_manifest.json

Verified the fix on Windows-10 using Chrome beta version #64.0.3282.113 as per the comment #0.
Attaching screen shot for reference.
Observed that no characters are superimposed and the PDF can be viewed properly.
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!

Deleted: cl verified 799699.PNG 372 KB

	cl verified 799699.PNG 372 KB View Download

Note: We are able to reproduce the issue on reported chrome version 64.0.3282.71, but the behavior is very inconsistent from our end i.e., the issue is seen only once in ten trials. Checked accordingly on chrome version 64.0.3282.113 at least 20-30 times, the issue is not seen on verified version.

Thanks!

Looks like we're good here. Closing as Verified based on #24 and #25.

mmm, KO with Version 64.0.3282.119 (Build officiel) beta (64 bits) with previous PDF test file.  on Win7 64bits French

Deleted: pdkko.png 67.3 KB

	pdkko.png 67.3 KB View Download

not solved in Version 64.0.3282.140 (Build officiel) beta (64 bits)

:( I'll take a look on my Windows 7 VM when I get a chance. It's hard for one to verify this bug is fixed if one can never reproduce it in the first place.

I have the PDF and the Chrome icon on the desktop.

Right after starting the Windows 7 VM, I just drag the PDF icon onto the Chrome icon, and I can hit this bug with 64.0.3282.140. If I just reload the PDF, the problem goes away though.

It's rather finicky. I was able to consistently reproduce it, and now I consistently cannot.

I'm also have same problem on Windows 7, but it doesn't have problem on windows 10 
https://bugs.chromium.org/p/chromium/issues/detail?id=809888

Deleted: ezgif-4-02203ff9c8.gif 2.6 MB

	ezgif-4-02203ff9c8.gif 2.6 MB View Download

I've been looking at this in response to comment 28, and in response to  bug 809888 . I have a potential fix for  bug 809888  that I hope to get into Canary soon.

I think this problem has been solved, maybe you can try update to latest stable version 64.0.3282.186 (Thu Feb 22 01:04:07 2018)

not solved in Version 65.0.3325.51 beta (64 bits), windows 7

Need 65.0.3325.78 or newer for M65.

yes, work for me now, the chrome update was not complete before.
Version 65.0.3325.88 beta