I can confirm that it works fine on M63 and Canary. TE, can we have a bisect? thanks

I can confirm it too.

Have a look at the attachment.

That's was ok in chrome v63.

Deleted: chrome 64 pdf rendering issue.PNG 11.4 KB

	chrome 64 pdf rendering issue.PNG 11.4 KB View Download

Bisecting to look for the fix landed on https://chromium.googlesource.com/chromium/src/+log/25e26d931f7c4237ab06051b1439a34e0af81326..1eeccacf80ebcd9d972cf42e6f76aa57863b4040, so r528765 fixed it.

Bisecting to look for the breakage landed on https://chromium.googlesource.com/chromium/src/+log/9e2ec4dfde8f3c4c3075a1aac6f66455dfb9ef6d..8d70100c8cdebeab7a960e4ea939ab28878624d2 -> r509051.

r528765 landed before M65, so only M64 is broken. The question here is do we merge fix(es) to M64.

Hi, We reported this issue and as you can see from the link that an enterprise organization is impacted. These PDF files are public facing and it would be great if this fix can be merged with M64 stable release. Do let us know if any other information is required.

Appatura Team

I think fixing this means creating a chromium/milestone/64 branch in the chromium.googlesource.com/chromium/src/third_party/freetype2 repo and applying

cc2f3cd [psaux] Correctly handle Flex features (#52846)

and then updating the m64 DEPS for third_party/freetype2 to point to that commit.

drott: I think you have all the permissions needed to do this if you want. If not I'll work on this as soon as I can.

Comment 7,8,9 combine 
I've tested on Google Chrome 64, Canary(66). 
My PDF was created with laravel Dompdf.
Text wasn't render propery on Print Preview or Print Out Paper

nb : It won't happen everytime because the error wasn't inconsistent.

re: comment 10 - if your issue is happening on Canary, then this is not your bug. Please file a new bug for your problem.

thestig@, would you be able to make a PDFium regression test out of this? 

In terms of merging to 64, unfortunately I don't think the impact is big enough to justify a merge to Chrome stable. 

It appears fixed in M65, which according to [1] promotes to stable in the week of  Mar 6th, 2018.

[1] https://www.chromium.org/developers/calendar

drott: I can try to make a PDF that triggers this bug and include that in the PDFium testing corpus.

I have locally built a Chromium at refs/tags/64.0.3282.140 and reproduced this issue, then cherry-picked in

cc2f3cdecff5a351e7e8961b9f2e389ab740231a [psaux] Correctly handle Flex features (#52846)

and verified that it fixes this issue. This is a very simple diff that cleanly applies. In that sense it is quite safe.

As a result, I'm requesting merge-review to

1. Create a chromium/milestone/m64 branch in the chromium/src/third_party/freetype2 repository at bec14f688925467be708f01378fbbf82e6b19b42 (where FreeType is for m64).

2. Cherry-pick cc2f3cdecff5a351e7e8961b9f2e389ab740231a onto the branch created in step 1.

3. Roll Chromium and Chrome DEPS for FreeType to the commit created in step 2.

This bug requires manual review: Request affecting a post-stable build
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

My advice is to wait until M65. I realize that it's a simple fix; however, we're already ramping-up M64, and if this isn't absolutely critical, let's wait til 65.

Re #13:

> drott: I can try to make a PDF that triggers this bug and include that in the PDFium testing corpus.

Thanks, that'd be great.

We're being hit by this bug as well. School administrators are somewhat concerned. It would be fantastic if this could be merged into a M64 patch instead of "wait a month".

We can confirm that this is accruing all across our schools district.  Reverting to v63 seems to be the solution for now.

 

I am sorry to say that that the correct rendering of pdf is as critical as the correct rendering of html page.

We work with dozens of architect that handle pdf plans all day long.

Theirs computers have been automatically update to v64 by the will of Google.
Now that everything has moved to the cloud, including pdfs, we will certainly not told them that they can take a break for a month.

By the way, thanks you to Google Engineers there, for their ongoing effort around this issue during the last few days !

It is critical for our school... This bug causing issues with all our SIS reporting services...

I'm sure it's been fixed in Canary Channel, maybe will update in Stable next update. I'm sure this is ridiculous, but you can try Chrome Canary if it's critical.

This is critical for my workplace.  We can't send conduct-related outcome letters, change of status notifications (when someone goes on a leave of absence), letters to parents of students, and more.  This is really handicapping our established systems... please fix asap.

Also crucial for us - same as above response.  And it is not feasible to push out canary to all our users, then remove canary and push back the normal release...

I'm re-requesting review for merge of the fix to m64. I wouldn't normally do this, but I think this is important. Since this merge was last rejected we have had six separate enterprise customers report here that this is very disruptive to their organization (not just themselves), and I have reason to believe there are more who simply haven't commented (this issue is quite starred). Note that the issue here is that the text in a large number of PDFs is being rendered horribly. Note that the screen capture in Comment #2 isn't entirely representative, the glyphs often look much worse.

Also, if the fix for  issue 809888  goes into m64 I'm concerned that that issue has been covering some reports for this one. In other words, if the fix for  issue 809888  is merged to m64, I think it important that this fix is merged as well.

Also note that this fix has been out in m65 and tip of tree for some time and is known to fix the issue.

At this point almost all the steps from Comment #14 above have already been done and verified locally, except commiting the change to Chrome DEPS. So this is a request to commit Chrome change 567082 , which contains links to all the details.

For an accurate representation of what our reports are looking like when printed please see attached scan of a printed pdf.

Deleted: SampleScan.pdf 53.0 KB

SampleScan.pdf 53.0 KB Download

That is what ours look like too.

It primarily happens when users try to print from Infinite Campus or our Helpdesk.

We have let both vendors know.


https://www.infinitecampus.com/

http://grouplink.com/products/everything-helpdesk/

@Comment 30: note that what is seen in SampleScan.pdf is actually not this issue, but  issue 809888 . Both of these issues are getting reports about the other. This one is when the characters are rendered poorly, the other is when they're drawn in the wrong place (and sometimes you can get both).

Approving for M64. Branch:3282

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/tools/buildspec/+/a93dbdccdeea6b9396990533fffcf701fd9a283f

commit a93dbdccdeea6b9396990533fffcf701fd9a283f
Author: Ben Wagner <bungeman@chromium.org>
Date: Fri Feb 16 22:57:06 2018

 Issue 813615  has been merged into this issue.

I have verified that the initial reproducing case no longer reproduces in at least 64.0.3282.181 . Before commenting further on this issue, please take a look at chrome://version and ensure that your version is greater than this. Also be sure that your issue isn't actually  issue 809888 .

Per Bug Description: When PDF is opened using Chrome Browser, some parts of text are rendered incorrectly. It was working fine in v63, issue exists in 64 and 65, disappears in Canary.

Just double checking, is there any fix/merge needed for M65?

Adding M-65 label for tracking purpose until we get update on comment #40.

64.0.3282.181 or higher will be an automatic update or we need to update manually? Currently our systems are showing 64.0.3282.167 and no new update available. Appreciate your help.

Appatura Team.

re: comment 40 - contrary to the original bug report, we believe this is a M64-only issue, per comment 3 / comment 4.

Thank you for confirming thestig@. Removing "M-65" label based on comment #44.

Can we identify which rev this landed in?  I'd like to confirm specifically for CrOS.

Thanks

re: comment 43 - We are looking into getting another 64.x release out to users. Hang on!
re: comment 46 - Are you referring to the fix on trunk, the fix on a particular branch, or when this broke?

Re 46/47:  For Chrome OS:  I need to know the first Chrome version with the fix for M64 and M65 since we'll likely have to uprev our RCs.

re: comment 48 - 64.0.3282.175 / 65.0.3319.0

Able to reproduce the issue on Chrome 64.0.3282.186/10176.74.0 - Kip. 
I'm seeing the issue on the following sample pdf file (issue/813615):
https://services.hbsp.harvard.edu/services/proxy/content/72850847/72850892/3a487eee07f1ef3fdc12cf13ab9634f3

I'm removing the 'fixed' status since Song reproduced per #50.   RBS, so please prioritize.

I also added this to crbug/810791:

The chrome-te team created crbug/814631 as a new stable blocker (BROWSE button no longer appears) for 66.0.3350.3/10427.0 testing.

Not sure if this is related, and/or if it'll also be an issue in 64.0.3282.186, but need to now if that or this bug persists as a blocker for M64 along with this one.

songsuk@ - can you please provide a quick screenshot of what you're seeing in #51?

Please see the attached file.  

Able to reproduce the issue on Chrome 66.0.3352.0/CrOS 10428.0.0 - Kip

Deleted: Screenshot 2018-02-22 at 10.04.54.png 172 KB

	Screenshot 2018-02-22 at 10.04.54.png 172 KB View Download

Disregard comments re: crbug/814631 in #52.  Confirmed no impact to 64.0.3282.186/10176.74 -kip

I'm able to reproduce commnent#51 on 66.0.3352.0/10428.0.0, 64.0.3282.186/10176.74.0, 65.0.3325.89/ 10323.39.0

It appears that CrOS uses its own version of FreeType, which seems to be at FreeType 2.8.1 + 107 commits at https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/media-libs/freetype/ . This will need cc2f3cdecff5a351e7e8961b9f2e389ab740231a cherry picked into it to pick up the fix.

Since everyone is updating their FreeType, I will also update FreeType for PDFium's 3282 branch. This has no effect on Chromium, as Chromium uses its own copy. It only benefits any external projects that follow PDFium's release branches. https://pdfium-review.googlesource.com/c/pdfium/+/27610

I created crbug/814883 to track Chrome OS specific merge requests and resolution steps.

Not sure why we need a separate cros  bug 814883 .... Anyway, I was about to upgrade FreeType to match other platforms. 

re comment 63:  bug 814883  is to simplify  merge request handling for CrOS. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/1fc50102ad006fa0cf8d7b6ec6729d1c34e7bc21

commit 1fc50102ad006fa0cf8d7b6ec6729d1c34e7bc21
Author: Jungshik Shin <jshin@chromium.org>
Date: Fri Feb 23 11:36:41 2018

Freetype: cherry pick cc2f3cde from the upstream

Flex feature in CFF is mishandled in FreeType leading the PDF
rendering to be broken. The upstream cc2f3cde fixd it.

cc2f3cd [psaux] Correctly handle Flex features (#52846)

BUG= chromium:810166 , chromium:814883 
TEST=emerge-<target> freetype
TEST=cros deploy <test device ip> freetype
TEST=https://goo.gl/5nMa1R (PDF file) is rendered properly (bug comment 54)
Change-Id: I39092d03a6acaad9e67cf8431a7495100d65106f
Reviewed-on: https://chromium-review.googlesource.com/932754
Commit-Ready: Jungshik Shin <jshin@chromium.org>
Tested-by: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/1fc50102ad006fa0cf8d7b6ec6729d1c34e7bc21/media-libs/freetype/freetype-2.8.1.ebuild
[add] https://crrev.com/1fc50102ad006fa0cf8d7b6ec6729d1c34e7bc21/media-libs/freetype/files/freetype-2.8.1-cc2f3cde.patch
[rename] https://crrev.com/1fc50102ad006fa0cf8d7b6ec6729d1c34e7bc21/media-libs/freetype/freetype-2.8.1-r2.ebuild

Desktop Chrome updated to 64.0.3282.186. Verified on Windows and Mac and original issue is fixed. Thanks for rolling out this update.

Appatura Team

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/57469c78c9ceee5c0f514794ed81e3d5776fd37d

commit 57469c78c9ceee5c0f514794ed81e3d5776fd37d
Author: Jungshik Shin <jshin@chromium.org>
Date: Fri Feb 23 21:07:23 2018

[Merge to R64] Freetype: cherry pick cc2f3cde from the upstream

Flex feature in CFF is mishandled in FreeType leading the PDF
rendering to be broken. The upstream cc2f3cde fixd it.

cc2f3cd [psaux] Correctly handle Flex features (#52846)

BUG= chromium:810166 , chromium:814883 
TEST=emerge-<target> freetype
TEST=cros deploy <test device ip> freetype
TEST=https://goo.gl/5nMa1R (PDF file) is rendered properly (bug comment 54)
Change-Id: I39092d03a6acaad9e67cf8431a7495100d65106f
Previous-Reviewed-on: https://chromium-review.googlesource.com/932754
(cherry picked from commit 701e1fbcec5bfa30d08a6b9f3c6f78085e44b685)
TBR=kbleicher@chromium.org,derat@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/935142
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Tested-by: Jungshik Shin <jshin@chromium.org>

[modify] https://crrev.com/57469c78c9ceee5c0f514794ed81e3d5776fd37d/media-libs/freetype/freetype-2.8.1.ebuild
[add] https://crrev.com/57469c78c9ceee5c0f514794ed81e3d5776fd37d/media-libs/freetype/files/freetype-2.8.1-cc2f3cde.patch
[rename] https://crrev.com/57469c78c9ceee5c0f514794ed81e3d5776fd37d/media-libs/freetype/freetype-2.8.1-r2.ebuild

The following PDF file is displayed properly on 66.0.3353.0/10433.0.0-Kip :

https://services.hbsp.harvard.edu/services/proxy/content/72850847/72850892/3a487eee07f1ef3fdc12cf13ab9634f3

Tested issue on 64.0.3282.190/10176.76.0 Stable-channel Reks and observed following PDF files displayed properly

PDF files:
1)https://services.hbsp.harvard.edu/services/proxy/content/72850847/72850892/3a487eee07f1ef3fdc12cf13ab9634f3

2)https://www.gsam.com/content/dam/gsam/pdfs/us/en/fund-literature/quarterly-fact-card/INST_EmergingMarketsEquityFund_300704_FC.pdf?sa=n&rd=n

Thanks..!!

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

commit b1040bcfc9782bfb387e4a2a7e7c1c6aa3c2c7d3
Author: Lei Zhang <thestig@chromium.org>
Date: Mon Feb 26 23:56:43 2018

M64: Roll FreeType to ff72e3b1.

https://chromium.googlesource.com/chromium/src/third_party/freetype2.git/+log/bec14f68..ff72e3b1

ff72e3b1 [psaux] Correctly handle Flex features (#52846).

Note: This only affects standalone PDFium and has no effect on Chromium.

BUG= chromium:810166 
TBR=bungeman@chromium.org

Change-Id: Ifa5be56638a1b95b2158b9c9498d28cfac5b9011
Reviewed-on: https://pdfium-review.googlesource.com/27610
Reviewed-by: Lei Zhang <thestig@chromium.org>

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

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/d7412c421c0b42d0b3868d1e1c5caf95c49331da

commit d7412c421c0b42d0b3868d1e1c5caf95c49331da
Author: Jungshik Shin <jshin@chromium.org>
Date: Tue Feb 27 21:24:42 2018

[R65-branch] Freetype: cherry pick cc2f3cde from the upstream

Flex feature in CFF is mishandled in FreeType leading the PDF
rendering to be broken. The upstream cc2f3cde fixd it.

cc2f3cd [psaux] Correctly handle Flex features (#52846)

BUG= chromium:810166 , chromium:814883 
TEST=emerge-<target> freetype
TEST=cros deploy <test device ip> freetype
TEST=https://goo.gl/5nMa1R (PDF file) is rendered properly (bug comment 54)
Change-Id: I39092d03a6acaad9e67cf8431a7495100d65106f
Previous-Reviewed-on: https://chromium-review.googlesource.com/932754
(cherry picked from commit 6e31ac40e78857887b0ebd949934b6dae3c7fdf3)
Reviewed-on: https://chromium-review.googlesource.com/939992
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Tested-by: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/d7412c421c0b42d0b3868d1e1c5caf95c49331da/media-libs/freetype/freetype-2.8.1.ebuild
[add] https://crrev.com/d7412c421c0b42d0b3868d1e1c5caf95c49331da/media-libs/freetype/files/freetype-2.8.1-cc2f3cde.patch
[rename] https://crrev.com/d7412c421c0b42d0b3868d1e1c5caf95c49331da/media-libs/freetype/freetype-2.8.1-r2.ebuild

Merged to R64 and R65. Verified in 66 and 64 branches of CrOS. 

Verified in R65 (CrOS) as well. See  bug 814883 . 

Thanks a lot to the chromium team there for your quick fix.

I filed bug 823907 for writing an automated test case for this.

re: comment 74 - you are welcome!