Should note option (3) would be to remove the feature entirely, which might be reasonable if the test case being fixed for me on Linux means that the garbled PDF text issue is fixed in general for Linux/CrOS users. 

- myself, +crivero in case we need further design help

If the original reason to have the feature "Print as image" was due to garbled text (sorry I don't recall), and if garbled text issue has been fixed, the option (3) seems a reasonable choice. 

It was due to garbled text. The problem is I am not sure if this has been resolved for all documents or only for the one specific test document. Maybe thestig@ has more insight on whether this has been fixed in general.

I don't have a specific test case, but bug 550205 explains why this feature is needed in general.

See bug 480628, bug 697182, and bug 704986 for test cases that may benefit from the "Print PDF as Image" feature. We may want to update those bugs while we are at it, if they happen to be fixed.

Fix proposal 1 sounds more consistent with the behavior of all the other setting changes. Given this is a rarely used feature, but super handy when one needs it, I think one more round of regeneration is worth the time spent.

FWIW, (1) is also the simplest to implement. It avoids adding yet another special case + associated logic to the Print Preview JS, and is more straightforward than pulling all the feature logic out. Another benefit to keeping this and doing the regeneration is that if we ever have any PDF font/rendering issues it can provide a temporary workaround for users on platforms that have the feature enabled, regardless of what type of printer they are using.

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

commit cd1539c5e2f2a50e59b47b1a857224f799559aa5
Author: rbpotter <rbpotter@chromium.org>
Date: Thu Mar 15 00:33:28 2018

Print Preview: Regenerate PDF for rasterization

Since the final PDF from print preview is now sent directly to the
printer in all cases, the PDF should be regenerated in all cases where
the user changes a setting that should modify the final PDF, including
"Print as Image".

Bug:  813267 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I49202c782c35209d319f146b272dd49c2d0cfd07
Reviewed-on: https://chromium-review.googlesource.com/963282
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Commit-Queue: Rebekah Potter <rbpotter@chromium.org>
Cr-Commit-Position: refs/heads/master@{#543257}
[modify] https://crrev.com/cd1539c5e2f2a50e59b47b1a857224f799559aa5/chrome/browser/resources/print_preview/new/preview_area.js
[modify] https://crrev.com/cd1539c5e2f2a50e59b47b1a857224f799559aa5/chrome/browser/resources/print_preview/preview_generator.js

Tried checking the issue on a sample pdf file(http://www.pdf995.com/samples/pdf.pdf) by enabling flag "Print Pdf as Image" and selecting "Print PDF as Image" check box on print preview. We observed blank pages are getting printed on both the chrome versions with and without fix.

@rbpotter: Could you please help us in verifying the fix by providing any sample test file.
Note: As per comment#5 checked the mentioned Bugs/Issues i.e., bug 480628(No test file found), the other two bug 697182 and bug 704986 are RVG.

Thanks!

The change here is actually partially verifiable without printing. You can check that the preview is regenerated when "Print as Image" checkbox is toggled.

Both test cases from those bugs are publicly available papers so I will link to them here:
https://quod.lib.umich.edu/cgi/p/pod/dod-idx/filter-design-using-second-order-peaking-and-shelving.pdf?c=icmc;idno=bbp2372.2004.152;format=pdf
Test case is printing page 4 and examining super and subscripted +/- signs. This one does not reproduce for me on the Ricoh (i.e. I see the signs regardless of the state of the "Print as Image" checkbox).

http://jmlr.csail.mit.edu/papers/volume10/weinberger09a/weinberger09a.pdf
Test case is printing page 5 and examining sigma and omega symbols. This does work as a test case with the Ricoh Aficio - i.e. symbols print incorrectly without "Print as Image" checkbox on 67.0.3372.0 build, and on 65.0.3325.146 Stable with or without the checkbox ticked, but they print out correctly from 67.0.3372.0 with the Print as Image checkbox selected.

Please note that results may vary by printer, i.e. the fact that symbols in a document print correctly on the Ricoh may not mean that they print correctly for all users.

Also, the print quality with and without "print as image" is typically visibly slightly different if you look closely at the text, because rasterizing the page results in lower quality printouts than printing the PDF directly. So you can just print for example https://www.irs.gov/pub/irs-pdf/f1040ez.pdf, which does not have any unprintable symbols, and look at the printout closely to verify it is slightly lower quality when printed with the checkbox. I am not sure why you are seeing blank pages as the document you linked prints correctly here.

Another note: You should not need to enable the flag, as this feature is on by default on Linux and ChromeOS, which are the two platforms where it is supported.

Requesting merge to M-66 for the change in comment 8 since it was an M-65 regression and should be a safe fix (change is only to print preview, and just updates the logic to match that of other settings in Print Preview). If desired, I can merge just the change in preview_generator.js, since the other change is for the new print preview UI which is in development behind a flag.

The bug is marked as P3 or Feature. It should not be merged as M66 is in beta. 
Please contact the approriate milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

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

Increasing priority to correctly reflect the fact that this is a regression and breaks a feature that is useful on Linux/CrOS (see bug 704986 for an example). The original lower priority was assigned before M65 went to Stable.

This bug requires manual review: M66 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), josafat@(ChromeOS), abdulsyed@(Desktop)

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

Approvng merge to M66. Branch:3359

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

commit 6f33da3f529d0d5aa62d0938c2f752a6dc486167
Author: rbpotter <rbpotter@chromium.org>
Date: Mon Mar 19 20:29:42 2018

Print Preview: Regenerate PDF for rasterization (M66)

Since the final PDF from print preview is now sent directly to the
printer in all cases, the PDF should be regenerated in all cases where
the user changes a setting that should modify the final PDF, including
"Print as Image".

Bug:  813267 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I49202c782c35209d319f146b272dd49c2d0cfd07
Reviewed-on: https://chromium-review.googlesource.com/963282
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Commit-Queue: Rebekah Potter <rbpotter@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#543257}(cherry picked from commit cd1539c5e2f2a50e59b47b1a857224f799559aa5)
TBR: dpapad@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/969188
Reviewed-by: Rebekah Potter <rbpotter@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#325}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/6f33da3f529d0d5aa62d0938c2f752a6dc486167/chrome/browser/resources/print_preview/new/preview_area.js
[modify] https://crrev.com/6f33da3f529d0d5aa62d0938c2f752a6dc486167/chrome/browser/resources/print_preview/preview_generator.js

> Verified this issue on Ubuntu 14.04 using chrome latest beta M66 #66.0.3359.45 by following test case provided in comment #10. Observed able to print the image as expected, Please check screenshot-1.

> Able to reproduce this issue on chrome M65 #65.0.3325.125 before fix, observed the image content is not printed as expected, Please check screenshot-2

> As per screenshot-1 adding TE-Verified label for M66.

Thanks!

> Attaching the screenshot as pdf file

Deleted: 66.0.3359.45.pdf 67.9 KB

66.0.3359.45.pdf 67.9 KB Download

Deleted: 65.0.3325.125.pdf 257 KB

65.0.3325.125.pdf 257 KB Download