Can you pls attach a sample pdf file so we can check on the problem? thanks

Sorry, it's a bank statement loaded with personal information and I don't want to share it. I'm open to suggestions here.

Can you pls try some general docs such as https://home.capitalone360.com/downloads/sample-estatement.pdf
https://home.capitalone360.com/downloads/COAF_eStatement_Overview.pdf
https://home.capitalone360.com/downloads/business-resolution-form.pdf

See if anyone has similar problems?

All of those documents load fine for me. I just re-downloaded a statement and it still renders poorly. The boilerplate fonts are OK, as are my name and address at the top, but the bulk of the statement is screwy.

I downloaded a tax form PDF from the bank and it was OK, too.

Without a test case this will be very difficult for us to track down. Do you have a windows or Mac you can open the file to see if it is still corrupted in Chrome? It's possible it's a missing font issue.

I opened up the file on a Mac with no trouble using Adobe Acrobat Pro. Significantly, though, Apple's Preview app had the same problem the Chromebook does.

The three fonts used in the file (according to Acrobat Pro's properties dialog box) are Helvetica, Helvetica-Bold, and Helvetica-Narrow, all Type I. On my Mac, Acrobat substitutes TrueType equivalents for the first two and Adobe Sans MM for the narrow. I don't have my Chromebook with me right now so I can't say what's happening there.

I believe that only Helvetica-Narrow is rendering poorly. The regular Helvetica and Helvetica-Bold type looks fine to me.

Thank you for providing more feedback. Adding "Needs-Review" label for tracking.

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

Can't be completely sure without a test case, but this seems to be the same bug about font substitution poorness. We probably do not have a font with similar char widths as Helvetica-Narrow, so the characters are not spaced properly. However, solving this is not very simple (it's not clear to me what the best solution will be in general: deforming the characters or reducing the font size, so that they fit). One way to do it, at least for Chrome OS, is to request addition of other fonts. I'm curious: in your Mac, do Adobe Acrobat Pro and Preview use the same substitute font for Helvetica-Narrow?

Adobe Acrobat Pro on my Mac renders the PDF fine. Apple Preview renders it poorly -- I think by tracking/kerning the letters closer. I just tried Chrome stable on Mac and it rendered nicely -- I'm not sure where it got a font to use. Screenshots attached.

Deleted: Screenshot Google Chrome MacOS PDF rendering.png 85.0 KB

	Screenshot Google Chrome MacOS PDF rendering.png 85.0 KB View Download

Deleted: Screenshot Adobe Acrobat Pro PDF rendering.png 57.4 KB

	Screenshot Adobe Acrobat Pro PDF rendering.png 57.4 KB View Download

Deleted: Screenshot Apple Preview PDF rendering.png 92.3 KB

	Screenshot Apple Preview PDF rendering.png 92.3 KB View Download

So on Chrome OS we either do not have a font even remotely close to Helvetica-Narrow, or we're just not choosing the substitute correctly... I'll try to get in touch with someone that knows more about those fonts.

Chrome OS has Arial Narrow which is pretty close to Helvetica Narrow, I believe. Kerning etc may not be exactly the same, but perhaps the best we have. 

BTW, one can complain to CapitalOne to embed the font in their PDF (Mac Preview has an issue, too). 

Lei, how/where is the fallback font determined for a missing font in pdfium? Apparently, pdfium is not using 'Arial Narrow' for 'Helvetica Narrow' on Chrome OS. 
(see the screenshot in comment 0). 

Adding a few more folks from OWNERS file in third_party/pdfium. 

Hmm, it looks like the mapping table at 

https://cs.chromium.org/chromium/src/third_party/pdfium/xfa/fxfa/app/xfa_fontmgr.cpp?rcl=0&l=278

needs to be updated (or specialized for Chrome OS). It does not mention any Noto fonts on CrOS. It does not have an entry for Helvetica Narrow, either. 

#elif _FXM_PLATFORM_ == _FXM_PLATFORM_LINUX_
const XFA_FONTINFO g_XFAFontsMap[] = {
    {0x01d5d33e, L"SimSun",
     L"WenQuanYi Zen Hei Mono,AR PL UMing CN,AR PL UMing HK,AR PL UMing TW,AR "
     L"PL UMing TW MBE",
     0, 936},
    {0x01e4f102, L"YouYuan",
     L"WenQuanYi Zen Hei Mono,AR PL UMing CN,AR PL UMing HK,AR PL UMing TW,AR "
     L"PL UMing TW MBE",
     1, 936},
    {0x030549dc, L"LiSu",
     L"WenQuanYi Zen Hei,WenQuanYi Zen Hei Sharp,WenQuanYi Zen Hei "
     L"Mono,WenQuanYi Micro Hei",
     1, 936},
    {0x032edd44, L"Simhei",
     L"WenQuanYi Zen Hei,WenQuanYi Zen Hei Sharp,WenQuanYi Zen Hei "
     L"Mono,WenQuanYi Micro Hei",
     1, 936},

For this particular issue, just adding an fallback entry (mapping 'Helvetica-Narrow' to 'Arial-Narrow') would suffice *if* that's where fallback fonts are selected. 

If that's the case, I can either do or help update the mapping tables with Noto fonts on CrOS. 

XFA forms are not yet enabled in Chrome. If OS_Linux, we use pepper, see
https://cs.chromium.org/chromium/src/pdf/pdfium/pdfium_engine.cc?sq=package:chromium&rcl=1483532378&l=162

Thank you for the pointer. In that case, how about adding an entry for 'Helvetica Narrow' to 'Arial Narrow' there and testing? 

For testing, I guess you can generate a PDF using ghostscript on Linux. 

Because 'Helvetica Narrow' is not available, perhaps 'Liberation Sans Narrow' can be used (NO font embedding). 

Then, for testing purpose, the table in comment 17 can have a fallback entry from 'Liberation Sans Narrow' to 'Arial Narrow'. 

I have created a test file that confirms the issue. Perhaps you are right and we should just map Helvetica Narrow to Liberation Sans Narrow in Linux. I'll look into it a bit more.

Deleted: helTest.pdf 2.2 KB

helTest.pdf 2.2 KB Download

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

commit b463c9f77352d48f56af0a0935f83d75665f469c
Author: pdfium-deps-roller <pdfium-deps-roller@chromium.org>
Date: Mon Jan 16 17:07:01 2017

Roll src/third_party/pdfium/ dd1bfe4b1..38c866022 (1 commit).

https://pdfium.googlesource.com/pdfium.git/+log/dd1bfe4b1438..38c8660228cc

$ git log dd1bfe4b1..38c866022 --date=short --no-merges --format='%ad %ae %s'
2017-01-13 npm Add default substitution for narrow fonts

BUG= 669893 

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, see:
http://www.chromium.org/developers/tree-sheriffs/sheriff-details-chromium#TOC-Failures-due-to-DEPS-rolls

TBR=dsinclair@chromium.org

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

[modify] https://crrev.com/b463c9f77352d48f56af0a0935f83d75665f469c/DEPS

Can't verify that reporter's problem is fixed. Please wait until the next version of ChromeOS is released to you and feel free to reopen this bug if it has not been fixed.

I've been toying around with plumbing font width in PDFium MapFont requests through PPAPI for a long time with only some partial success, as part of  bug 309664  and  bug 431507 . This solution has some hard coded names, but I imagine they are pretty stable. It is also a lot simpler and may benefit other PDFium users as well.

We should check those two bugs to see if this fix affected them.