Reproduced and confirmed this is a regression from 59 to 60. Happened on Windows 7, did not happen on Linux.

Can confirm issue is related to v60. We are experiencing the same with embedded images on PDF and printed from Chrome.

Works fine v58 and v59. No image on v60.

Deleted: test.pdf 1.5 MB

test.pdf 1.5 MB Download

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

commit 0f6ceba6bf6a966c1946aec2ff985dc2728fd71b
Author: rbpotter <rbpotter@chromium.org>
Date: Thu Aug 10 21:36:19 2017

Temporarily disable image mask individual rendering

Bug:  chromium:753700 
Change-Id: I28589739f4258fa62f3f853aa91bc6cffd7d96ba
Reviewed-on: https://pdfium-review.googlesource.com/10611
Commit-Queue: Rebekah Potter <rbpotter@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>

[modify] https://crrev.com/0f6ceba6bf6a966c1946aec2ff985dc2728fd71b/fpdfsdk/fpdfview.cpp

 Issue 755038  has been merged into this issue.

Should be fixed on the latest Canary (62.0.3185.0). Both the PDF examples printed correctly here on Windows 10 with that build. If anyone still has this issue on Canary, please update so we can investigate what might still be going wrong.

I installed Canary and tested with a couple of our PDFs and it seems to be fixed indeed. 

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

commit 8d7672e941fa58326c4c6aeac47418e9b36527e9
Author: rbpotter <rbpotter@chromium.org>
Date: Thu Aug 17 00:06:48 2017

Fix some issues with individual image mask rendering

Re-enable individual image mask rendering to improve spool sizes, with
bug fixes and improvements:
- Fix bug with missing images by ensuring all masks are recorded
- Fix printing to landscape paper sizes
- Improve spool sizes by processing the location of the masks in the
progressive renderer when rendering to the printer instead of needlessly
fully rendering them (they will be rendered as bitmaps anyway).

Bug:  chromium:753700 
Change-Id: I86bdcce9f10855274c56ba2ddae2c2522b36426d
Reviewed-on: https://pdfium-review.googlesource.com/11115
Commit-Queue: Rebekah Potter <rbpotter@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>

[modify] https://crrev.com/8d7672e941fa58326c4c6aeac47418e9b36527e9/core/fpdfapi/render/cpdf_progressiverenderer.cpp
[modify] https://crrev.com/8d7672e941fa58326c4c6aeac47418e9b36527e9/core/fpdfapi/page/cpdf_streamcontentparser.cpp
[modify] https://crrev.com/8d7672e941fa58326c4c6aeac47418e9b36527e9/core/fpdfapi/render/cpdf_renderstatus.h
[modify] https://crrev.com/8d7672e941fa58326c4c6aeac47418e9b36527e9/fpdfsdk/fpdfview.cpp
[modify] https://crrev.com/8d7672e941fa58326c4c6aeac47418e9b36527e9/core/fpdfapi/render/cpdf_renderstatus.cpp

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

commit 77d8317f2e6bb9c75d96390fdf843b86694ba6d2
Author: Dan Sinclair <dsinclair@chromium.org>
Date: Wed Aug 23 12:52:19 2017

Verify image returned from AddImage

The ::AddImage call can return a nullptr if there is no stream provided.
This CL adds the missing null check on the returned object when lookikng
at the image.

Bug:  chromium:756418 ,  chromium:753700 
Change-Id: I48032c0f421c8889827540ae91f404ef0f503bfe
Reviewed-on: https://pdfium-review.googlesource.com/11532
Reviewed-by: Rebekah Potter <rbpotter@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>

[modify] https://crrev.com/77d8317f2e6bb9c75d96390fdf843b86694ba6d2/core/fpdfapi/page/cpdf_streamcontentparser.cpp

Can this issue be fixed without Canary? I need this to work without additional software due to these being work computers controlled by corporate IT.

Requesting merge for initial quick-fix CL (comment 6) to 61, which restores the M59 behavior and is a relatively small change that should be straightforward to merge.

We can let the subsequent improvements/fixes (comments 10-11) roll out normally in M62.

This bug requires manual review: We are only 6 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid@(ChromeOS), govind@(Desktop)

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

Thank you  rbpotter@.
We already cut M61 Beta RC for release tomorrow. So if merge this fix (cl listed at comment 6) will directly to M61 Stable. This is M60 regression. Can't this wait until M62? 

Can probably wait until M62, as this is only a subset of PDFs and as you mention regressed in M60. Requested as it is obviously a significant issue for users who work with those PDFs regularly, and the change is a revert back to M59 rather than a new addition/fix. However, definitely understand if we are too close to M61 stable at this point.

It should be safe to merge, since we are reverting back to the M59 behavior, which is less efficient in terms of spool job size, but correctness is more important. The merged CL is Windows only and only affects printing.

Approving merge for CL listed at #6 to M61 branch 3163 based on comments #13, #16 and #17. Please merge ASAP. Thank you.

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

commit 0a49b11d0215c386cafe739c552780542cbe5824
Author: Lei Zhang <thestig@chromium.org>
Date: Wed Aug 30 22:44:56 2017

M61: Temporarily disable image mask individual rendering

Bug:  chromium:753700 
Change-Id: I28589739f4258fa62f3f853aa91bc6cffd7d96ba
Reviewed-on: https://pdfium-review.googlesource.com/10611
Commit-Queue: Rebekah Potter <rbpotter@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
TBR=rbpotter@chromium.org
(cherry picked from commit 0f6ceba6bf6a966c1946aec2ff985dc2728fd71b)
Reviewed-on: https://pdfium-review.googlesource.com/12510
Commit-Queue: Lei Zhang <thestig@chromium.org>

[modify] https://crrev.com/0a49b11d0215c386cafe739c552780542cbe5824/fpdfsdk/fpdfview.cpp

Merge to M61 in PDFium. On branches, Chrome pulls the latest corresponding PDFium branch, so there's no need for a DEPS roll.

Tested the issue on Windows-10 using chrome latest Beta M61-61.0.3163.73 on Printer-RICOH(MPC3003) by following steps mentioned in the original comment. Observed that PDF print is displaying as expected. Hence adding TE-Verified label.

Please find the screen shot for reference.

Thank you!

Deleted: 753700.pdf 405 KB

753700.pdf 405 KB Download