There is another report https://bugs.chromium.org/p/chromium/issues/detail?id=810166
how to merge into that?

This is not the same as  issue 810166 . I'm not sure what I'm looking at in 1.png and 2.png. I'm assuming that 2.png is what the PDF output by DomPDF looks like when viewed in Chrome? Does it look different when viewed in Acrobat? What is 1.png a screen capture of? Can you provide a PDF which reproduces this issue (with made up content, of course). I'm assuming this started at some Chrome version and is currently present in Canary?

We have the same issue with v64 in our organization.  It's so impactful that I've had to tell users to use another browser for anyone generating reports.  The issue looks exactly as shown in the picture 2, the characters are all stacked on one another in the left most column of a row.

When downloaded from Chrome locally and opened in Acrobat the file is fine.  

I'm assuming this started happening in 64? Can you determine if this still happens with the current Chrome beta / dev / canary? From the descriptions this doesn't appear to be an issue with Chrome's PDF generation but with the viewer. If anyone experiencing this can provide a PDF which demonstrates the issue it will be much easier to narrow down the cause.

I will try to get a PDF that this occurs with - however, unfortunately it's very sporadic and hard to pin down (plus I have to figure out one that I can provide without sensitive data).  I will run the same report twice, and once it will look garbled, and the next time I run it it looks fine.

Same goes for printing - sometimes it looks ok on the screen, but when printing becomes garbled with the "all characters on the left" bug.  

When opening these files in Acrobat we do not see the issues.  

We have found that since 64 this issue of stacking characters has started.  Sometimes the print preview will be fine and a few characters will stack on the printed version.  Other times the entire document will appear "garbled" on both the preview and the actual physical print job. The same document printed from Adobe or from Internet Explorer prints as expected.  We have also found that if we use Google Cloud print to the same network printer it occasionally will print to physical form just fine.  It seems like it is a combination of how Chrome is handling the PDF and print drivers.   I agree with Comment 6 that this is very difficult to pin down.

This could be a PDFium issue, so copying someone more familiar with that side of things to see if they might know anything about this.

I'm been testing on Chrome Stable v64, Chrome Canary v66, even latest Chrome Dev build from https://www.chromium.org/getting-involved/dev-channel. 
It's all happen sometimes, 
example : I print the file with 2 pages, first page was ok, but second page wasn't render properly like the picture.
It's was happen in v64, it's was okay in v63 before.

Here i'm also provide pdf with some dummy text. It's also happening when i'm create this file.

Deleted: example dummy text.pdf 2.0 KB

example dummy text.pdf 2.0 KB Download

Deleted: example.pdf 2.8 KB

example.pdf 2.8 KB Download

Deleted: error.png 22.8 KB

	error.png 22.8 KB View Download

Is this only happening on Windows 7? I think this may be  bug 799699 .

I also need help to understand if this is a Chrome PDF Viewer rendering problem, irregardless of whether printing is involved or not. Do PDFs render correctly in the Chrome PDF Viewer in the first place?

- If the PDFs do not render correctly, I have no expectation that they would print correctly.
- If the PDFS do render correctly, but then renders incorrectly in print preview, please reply and indicate this is what's happening.

re comment 10 : 
I'm currently using Windows 7, Moving to test on Windows 10.


re comment 11:
It's not consistent.
-Even Chrome PDF Viewer render properly, print out would be different from viewer. 
-Chrome PDF Viewer render not properly, but print out just fine.
-or It just fine both.

Yes,  bug 799699  has been driving me crazy too because the repro is inconsistent. When you think you fixed it, you are not 100% sure if you actually fixed it. This is certainly related.

Okay, i'm done testing it with Windows 10 Home, 
So i'm reinstall Google Chrome Stable in My Windows 7, delete whole Chrome data and record the screen.
I'm using a bunch of dump pdf, and on first try, i can tell it's affect Windows 7 very much.

there is no issue with Google Chrome Stable with Windows 10 Home as i test  it multiple times with same files.

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

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

Deleted: PDF dummy for test.zip 24.7 KB

PDF dummy for test.zip 24.7 KB Download

I believe it is correct that this is only happening with Windows 7.  I haven't gotten any reports of it occurring with our Windows 10 Educational installations, but I've gotten at least a dozen reports of it happening and they're all on Windows 7 x64.  

Actually, scratch that - I believe a different issue happens with Windows 10.  I haven't been able to replicate the display issue where text is stacked on one another when viewing the PDF - however, I have printed PDFs and had NO text come out (but the rest of the PDF does print, and it looked fine on the screen)  

I think I know what's going wrong. r519471 converted a synchronous IPC message from child processes to the browser into an asynchronous Mojo call. I'll try to finish it soon and available on Canary channel for testing.

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

commit c80f34c6c7a65103533f4d402917d27d8abba368
Author: Lei Zhang <thestig@chromium.org>
Date: Tue Feb 13 20:38:25 2018

Change FontCacheWin::PreCacheFont() to be synchronous.

It was incorrectly changed to be asynchronous in r519471. This causes
the font pre-cache mechanism to become unreliable, as there is no longer
a guarantee that the pre-caching will occur before the font is used.

BUG= 809888 

Change-Id: I15d14200c241089ae7d365a6ed0a61b119214e43
Reviewed-on: https://chromium-review.googlesource.com/914511
Reviewed-by: Ken Rockot <rockot@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536457}
[modify] https://crrev.com/c80f34c6c7a65103533f4d402917d27d8abba368/content/common/font_cache_dispatcher_win.cc
[modify] https://crrev.com/c80f34c6c7a65103533f4d402917d27d8abba368/content/common/font_cache_dispatcher_win.h
[modify] https://crrev.com/c80f34c6c7a65103533f4d402917d27d8abba368/content/common/font_cache_win.mojom

This should be fixed in 66.0.3347.0 or newer on the Canary channel. To be released in a day or two. Please try it out and make sure that's indeed the case. We'll work on merging to fix to release channels once we are sure the fix works.

Unable to reproduce the issue on chrome reported version 64.0.3282.140 using windows-7 with steps mentioned below:
1) Launched chrome reported version and loaded the pdf files provided in comment#9 & 14 and checked the behaviour of the pdf
2) Able to see the text as excepted on normal window and preview window
Observations: As per comment# 10, check the behaviour of the pdf provided in issue:  799699 , but unable to reproduce the issue

@thestig:
Please find the attached screencast for your reference, and help us in verifying the fix.

Thanks!

Deleted: 809888.mp4 2.9 MB

	809888.mp4 2.9 MB View Download

@viswa.karala The issue is seems to be inconsistent. I downloaded the same files this morning and they opened blank or with stacked characters. When I went to create a screencast 5 minutes later to demonstrate, the files opened just fine on screen and printed properly in ver 64.0.3282.140 on Windows 7.  I will try and replicate again later and see what happens.  

Re comment 20, 22 :
You need to clear all cache, history, or just delete all data to create a consistent error .
 Also @thestig said  it problem was font cache，i’m suspect chrome cached the text so it was hard to recreate error without clear the cache.

Adding conops hotlist as FYI.

So has anyone tried 66.0.3347.0 or newer on Canary channel to see if issue has gone away for good?

re: comment 20 - as mentioned numerous times, this bug is hard to reproduce consistently. I've found the most likely chance of reproducing it is to reboot the computer and try reproducing this immediately after the reboot.

In any case, I'm going to recommend merging to M64 and M65. As this restores the behavior in Chrome 63 where the Chrome PDF Viewer would wait for the browser to warm up the font cache before trying to render. So let's start with a M65 merge request.

re: comment 23 - No, you don't have to clear your browser cache. The font cache being discussed here is in Windows.

This bug requires manual review: M65 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

Is the change verified in canary and safe to merge to M65?

I have trouble reproducing the bug consistently in the first place, so I haven't been able to verify it myself. Looking at the CL that caused this problem, I know r536457 is the right fix. PDF text rendering works in Canary, and I'm confident my fix won't break anything else.

Approving merge to M65 branch 3325 based on comment #30. Please merge ASAP. Thank you.

Pls request a merge for M64 if you think it is imp to merge there.

+abdulsyed@ to evaluate M64 merge.

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

commit 891f32288f1e93df2b7b244857704dd070a4328b
Author: Lei Zhang <thestig@chromium.org>
Date: Thu Feb 15 23:24:20 2018

M65: Change FontCacheWin::PreCacheFont() to be synchronous.

It was incorrectly changed to be asynchronous in r519471. This causes
the font pre-cache mechanism to become unreliable, as there is no longer
a guarantee that the pre-caching will occur before the font is used.

BUG= 809888 
TBR=thestig@chromium.org

(cherry picked from commit c80f34c6c7a65103533f4d402917d27d8abba368)

Change-Id: I15d14200c241089ae7d365a6ed0a61b119214e43
Reviewed-on: https://chromium-review.googlesource.com/914511
Reviewed-by: Ken Rockot <rockot@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#536457}
Reviewed-on: https://chromium-review.googlesource.com/923091
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#485}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/891f32288f1e93df2b7b244857704dd070a4328b/content/common/font_cache_dispatcher_win.cc
[modify] https://crrev.com/891f32288f1e93df2b7b244857704dd070a4328b/content/common/font_cache_dispatcher_win.h
[modify] https://crrev.com/891f32288f1e93df2b7b244857704dd070a4328b/content/common/font_cache_win.mojom

Per comment 30, we should consider #32 for m64 as well. Since this is being faced by a significant number of users. But since we've been unable to repro this, is there any way we can have someone test this in Canary and confirm it as well?

Able to reproduce the issue on chrome reported version 64.0.3282.140 using Windows-7
Verified the fix on Windows-7 on Chrome version #65.0.3325.88 as per the comment#30
Attaching screen cast for reference.
Observed "Able to see the opened page renderring clearly"
Hence, the fix is working as expected.
Adding the verified label.

Thanks!

Deleted: 809888.mp4 1.9 MB

	809888.mp4 1.9 MB View Download

I'm trying to figure out when this fix will be incorporated into regular ol' Chrome, as opposed to Chromium/Canary. As of writing, the latest version of the official build of Chrome is 64.0.3282.167.

When I look here https://storage.googleapis.com/chromium-find-releases-static/c80.html#c80f34c6c7a65103533f4d402917d27d8abba368 I see this fix was merged to 65.0.3325.78. I take it that means this fix will be included whenever the official, stable build of Chrome hits that version or higher? Anywhere I can look to see when the target release date for that is? Thanks!

re: comment 36 - We are going to fix this for Chrome 64. We have decided to revert the bad CL for M64, instead of backporting the incomplete fix from M65 / M66. M65 / M66 still needs a bit more work.

We have an estimated release calendar here: https://www.chromium.org/developers/calendar

+jam@ FYI

To revert r519471, we need to also revert r519598.
https://chromium-review.googlesource.com/c/chromium/src/+/929428
https://chromium-review.googlesource.com/c/chromium/src/+/929344

Confirmed with ken@ and thestig@ - these reverts should be clean, safe, and shouldn't introduce any new regressions. Approving merge for M64. Branch:3282

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

commit bf043ba3cf8f7ff88712522a60cbae329fce6b2e
Author: Lei Zhang <thestig@chromium.org>
Date: Wed Feb 21 22:03:48 2018

M64: Revert "remove child_process_messages.h"

This reverts commit 0e5b75f5b75d5a9c50871fca910d8f2918f2d354.

BUG= 809888 
TBR=jam@chromium.org
Original CL: https://chromium-review.googlesource.com/783912

Change-Id: I51cfe7527b0935ce8a6a698d1799cd5824789469
Reviewed-on: https://chromium-review.googlesource.com/929428
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#692}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/browser/browser_child_process_host_impl.cc
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/browser/histogram_controller.cc
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/browser/ppapi_plugin_process_host.cc
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/browser/renderer_host/render_message_filter.cc
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/browser/renderer_host/render_process_host_browsertest.cc
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/child/child_histogram_fetcher_impl.cc
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/child/child_thread_impl.cc
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/common/BUILD.gn
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/common/child_process_host_impl.cc
[add] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/common/child_process_messages.h
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/common/content_message_generator.h
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/ppapi_plugin/ppapi_blink_platform_impl.cc
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/ppapi_plugin/ppapi_thread.cc
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/renderer/dom_automation_controller.cc
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/renderer/gpu/gpu_benchmarking_extension.cc
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/renderer/render_thread_impl.cc
[modify] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/renderer/renderer_blink_platform_impl.cc

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

commit 2fbd7b2d1dd65428e2e3d332f82aa3999c8b81c4
Author: Lei Zhang <thestig@chromium.org>
Date: Wed Feb 21 22:04:53 2018

M64: Revert "Mojo-ify PreCacheFont/ReleaseCachedFonts IPCs for windows"

This reverts commit 33a2d10d42fcb82679cc9fb5642153a0d4ac9b50.

Made windows-only typemap for LOGFONT using the existing
IPC ParamTraits.

BUG= 809888 
TBR=jam@chromium.org
Original CL: https://chromium-review.googlesource.com/787052

Change-Id: I3c796891563877ece7c1ac6fe4cbbdc0384d5a8f
Reviewed-on: https://chromium-review.googlesource.com/929344
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#693}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/2fbd7b2d1dd65428e2e3d332f82aa3999c8b81c4/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/2fbd7b2d1dd65428e2e3d332f82aa3999c8b81c4/content/browser/service_manager/common_browser_interfaces.cc
[modify] https://crrev.com/2fbd7b2d1dd65428e2e3d332f82aa3999c8b81c4/content/child/child_thread_impl.cc
[modify] https://crrev.com/2fbd7b2d1dd65428e2e3d332f82aa3999c8b81c4/content/child/child_thread_impl.h
[modify] https://crrev.com/2fbd7b2d1dd65428e2e3d332f82aa3999c8b81c4/content/common/BUILD.gn
[modify] https://crrev.com/2fbd7b2d1dd65428e2e3d332f82aa3999c8b81c4/content/common/child_process_host_impl.cc
[modify] https://crrev.com/2fbd7b2d1dd65428e2e3d332f82aa3999c8b81c4/content/common/child_process_messages.h
[modify] https://crrev.com/2fbd7b2d1dd65428e2e3d332f82aa3999c8b81c4/content/common/font_cache_dispatcher_win.cc
[modify] https://crrev.com/2fbd7b2d1dd65428e2e3d332f82aa3999c8b81c4/content/common/font_cache_dispatcher_win.h
[delete] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/content/common/font_cache_win.mojom
[modify] https://crrev.com/2fbd7b2d1dd65428e2e3d332f82aa3999c8b81c4/mojo/common/BUILD.gn
[delete] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/mojo/common/logfont_win.mojom
[delete] https://crrev.com/bf043ba3cf8f7ff88712522a60cbae329fce6b2e/mojo/common/logfont_win.typemap
[modify] https://crrev.com/2fbd7b2d1dd65428e2e3d332f82aa3999c8b81c4/mojo/common/typemaps.gni

Able to reproduce the issue on chrome reported version 64.0.3282.140 using Windows-7
Verified the fix on Windows-7 on Chrome version #64.0.3282.186 as per the comment#30
Attaching screen cast for reference.
Observed "Able to see the opened page renderring clearly"
Hence, the fix is working as expected.
Adding the verified label.

Thanks!

Deleted: 809888 - 64.0.3282.186.mp4 1.9 MB

	809888 - 64.0.3282.186.mp4 1.9 MB View Download

Per comment #37, M65/M66 still need more work. So reopening this bug for tracking purpose.

The "more work" is  bug 813101  and then  bug 814984 .

 Issue 813575  has been merged into this issue.

It would seem that some of the issues have been resolved.  Now we are seeing that some of the fields that would have previously "stacked" are now just printing blank in Ver 64.0.3282.186

re: comment 47 - Please file a separate bug and we can look into that too.