It's not a problem in Chrome's PDF plugin, but in Google Drive's rendering of the PDF.
The file is rendered correctly when opened locally in Chrome, but incorrectly when viewed via the first link in google drive.

Based on comment 3, should this be WontFix? We'd be happy to file a bug with the Google Drive team on your behalf.

Original bug reporter: Can you confirm you were using Google Drive inline PDF Viewer and not Chrome's PDF Viewer? The Drive PDF Viewer has the zoom buttons on the bottom edge. Chrome's PDF Viewer has them on the bottom-right corner.

Some comments:
* I checked on Linux/Windows, and Drive does not show the bold but Chrome does. So technically this is not the correct bug tracker for this.
* The fonts are of course not embedded, the only way to know it is actually supposed to be bold is with the Flags on the FontDescriptor.
* I wonder if this is a problem with Drive having a poor choice of fonts available when they call PDFium to render the PDF, or if PDFium does a poor selection among those fonts.

* The issue is not with Google Drive , For the sample I have uploaded in the Drive.
* You can download the file attached and open with the google chrome so that you can simulate this issue.
* Also try to open in the windows 10 os since we all are using the Windows 10 OS so it may possibily able to simulate the issue with windows 10 on chrome browser by opening the file attached on the chrome.

Deleted: pdf_test.pdf 9.8 KB

pdf_test.pdf 9.8 KB Download

Thank you for providing more feedback. Adding requester "thestig@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

Oh it may be a Windows10-only issue. Before, I checked on Windows 7 using the drive link from the bug report. But I can confirm this is a problem in Chrome using Windows 10, with the file on #7. Note that this is a problem in both M63 and canary, so... most likely not a regression.

I can work on this once I get hands on a workstation that I can actually code in. The Win10 in our windows lab is unnervingly slow. If this needs a more tight timeline for resolution, the real PDFium team can take this bug from me.

Thanks for your reply , so when can i expect the fix to be in the chrome ?

Since our application is testing phase in Chrome we need his issue has to be resolved as soon as possible.

This bug has been around for a while, does not seem to significantly impact user experience, and seems to only be reproducible in Windows 10. So I don't think it's highest priority for the PDF team. I don't have a timeline of when it will be fixed (I have not started working on it so don't have a sense of how hard it will be to fix). Once I do, I will update this bug.

I tested the link on Chrome (64.0.3282.140), Edge, and IE. All of them rendered the calibri line incorrectly. 

When the file was downloaded and opened locally, Chrome had the error, while Edge, IE, and Adobe Reader displayed it correctly. All of that was on Win 10.

The link displayed incorrectly for Chrome and IE on a Win 7 VM. 

When we can expect the fix to be in Chrome?

Assigning all my PDF bugs to dsinclair@ for triaging. Will not be working on PDFium for a month.

Hi guys, thought I'd add to this bug as I'm experiencing a similar issue.

I have had the problem now with Avenir, Verdana and Open Sans. We are generating PDF's in our app environment, and the rendering is buggy when viewed in Chrome. 

The PDF's view fine when opened in Acrobat Reader on the source machine (Win 10 instance in AWS), however when opened in Chrome they render inconsistently. Sometimes Bold/Normal text is inverted, so instances of normal text become bold. Other times the entire document is shown in bold. We have also seen it make some pages in a document completely bold, whereas other pages render correctly.

When the same document is brought onto a workstation in the office (OSX environment), the documents display fine in Acrobat reader, Safari and Firefox, however in Chrome (osx) they also display these weird rendering issues.

Where this differs from the original bug submission is that this behaviour is seen in the default chrome PDF viewer - not a Google Drive doucment.

Deleted: Screen Shot 2018-04-13 at 2.45.33 pm.png 336 KB

	Screen Shot 2018-04-13 at 2.45.33 pm.png 336 KB View Download

Hi Team,

When can we expect a fix which would resolve this issue in the Chrome?

Since we are waiting for migration from IE to Chrome only due to this issue , so kindly let us know the exact date when it can be fixed.

The bug is on our backlog but we have other work that we need to be done before someone will be available to look at this. We will update the bug when work has started.

Setting PDF bugs assigned to me back to untriaged so they can get re-assigned as needed.

Similar problem, the attached PDF renders Bold fonts correctly in Edge, Firefox, Adobe and Chrome for Windows 7.
In chrome for Windows 10 the Bold fonts are ignored. (version 71).

Deleted: PDF753484564.pdf 2.3 KB

PDF753484564.pdf 2.3 KB Download

FWIW bisected to r411761 = 8f7a478791623f4af72be16da30817f6ff753175 = crrev.com/2243953002
"Add Win32k lockdown for PPAPI processes to finch testing parameters."
Landed in 54.0.2828.0

Confirmed by observing bold fonts when running chrome --disable-win32k-lockdown

re: comment 20 - Can you file a separate bug for your issue? The symptoms may be similar, but PDF fonts are complicated, so it's not obvious if they are the same issue.

re: comment 21 - Did you bisect the PDF for the original bug or the PDF in comment 20?

I cannot reproduce this issue in Chrome anymore with pdf_test.pdf. Can anyone confirm?

I think https://pdfium.googlesource.com/pdfium.git/+/a2edb51d fixed this in Chrome 68.

And I bisected the issue with pdf_test.pdf to a range that includes r505649, so I think this bug is a duplicate of  bug 820345 . Same root cause and same fix.

Comment 21's bisect is for 20's PDF753484564.pdf

I filed bug 923086 for comment 20. I'm marking this bug as a duplicate.

Thanks thestig@chromium.org .