Able to reproduce the issue with latest Chrome stable i.e., 59.0.3071.86 on Windows 7,10, Mac and Linux. 

I see similar behavior on latest Chrome Beta, Dev and Canary, Working on bisect will update the result soon.

Please find the bisect range : 

You are probably looking for a change made after 461950 (known good), but no lat
er than 461951 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/bac4a9787174ce5e4bb7c4dded78f60550d667ba..06596a6f56b2b5ce13859d05f5b2a9434ee55a64

cc'ing  rbpotter@ since I see Lei is OOO today.

 andy.hair@ just curious to know is this only pdf where you are seeing the issue, Since when I tried other PDF's I wasn't able to reproduce the issue. Please let us know.

cc'ing Alex and Christine to reproduce the issue on Mobile side as well.

Please remove the Android label if this isn't applicable.

+gkihumba@ - for ChromeOS

@pbomm... Our software produces a few documents like the attached where they will have a property brochure along with a covering letter. They are essentially 2 documents which are joined into 1 PDF when the final document generation takes place. The issue seems as though only the 1st part of the document is recognised. Our software also produces singular documents eg letters or single brochures and they print fine

There's no Chrome PDF Viewer on Android.

@candr.. On Android I guess you would download it. I know in Windows if the PDF is downloaded and printed from Adobe then the job prints as expected. 

The issue is this CL:
https://pdfium.googlesource.com/pdfium.git/+/abf16c0682a545db4e9bae5510dd398a6ae634a3

Specifically the problem seems to be the change to check len <= 0 vs len < 0 here: https://cs.chromium.org/chromium/src/third_party/pdfium/core/fpdfapi/parser/cpdf_syntax_parser.cpp?l=730

This can't be reversed easily at tip of tree or anywhere after the following commit: https://pdfium.googlesource.com/pdfium.git/+/5b590337e0778b49dd7092af4a283ed0f9c5a2e9 as this commit adds an assert that fails if you allow length = 0 through.

@dsinclair if its any use we could have a skype chat and I can screen share and show you the issue in more detail

What does bringing up print preview do differently vs displaying the PDF? The PDF renderers correctly in the chrome viewer, it's just on print preview that things go weird?

The problem is that the document contains zero length streams. So, when the CPDF_Creator code is running to generate the print PDF the stream decode will exit early and the creator code will exit and not generate the page.

25 0 obj
<<
/Filter /FlateDecode
/Length 0                                                                                                                        
>>
stream
endstream
endobj

I don't think this needs to block M59, I can merge the fix into Beta once it's baked for a few days if desired, but this seems like a bit of an edge case.

andy.hair@ is there a reason why your software is generating streams with length of 0? (I can see a bunch of them in the document you provided, objects 25, 26, 29, 30, 34, 35, 38, and 39.)

As an update, it isn't the save code that doesn't like zero length streams, it's the FPDF_ImportPages code which is early exiting. This is what chrome uses when it's generating the print preview PDF.

CL: https://pdfium-review.googlesource.com/c/6490/

@dsinclair the tool we use to create them is http://www.evopdf.com/. It did work fine on the previous build of Chrome not sure why streams are being generated with 0 length though

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

commit 957480c17682008ae2a14723868fcdcab89b6577
Author: Dan Sinclair <dsinclair@chromium.org>
Date: Tue Jun 13 19:33:05 2017

Allow zero length streams when parsing.

It's possible to create a stream of length 0 in a PDF document.
Currently the code will early exit and return a nullptr. This causes
issues when you want to print the given PDF as the FPDF_ImportPages code
ends up only generating up to the zero length object.

This CL allows creating streams with length 0 and updates the PDF saving
code to output a blank stream.

Bug:  chromium:732380 
Change-Id: I44182ba4aaac7c51284b002ba01bbc34b6bcf9e0
Reviewed-on: https://pdfium-review.googlesource.com/6490
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>

[add] https://crrev.com/957480c17682008ae2a14723868fcdcab89b6577/testing/resources/zero_length_stream.pdf
[modify] https://crrev.com/957480c17682008ae2a14723868fcdcab89b6577/testing/embedder_test.h
[modify] https://crrev.com/957480c17682008ae2a14723868fcdcab89b6577/core/fpdfapi/parser/cpdf_syntax_parser.cpp
[modify] https://crrev.com/957480c17682008ae2a14723868fcdcab89b6577/testing/embedder_test.cpp
[modify] https://crrev.com/957480c17682008ae2a14723868fcdcab89b6577/fpdfsdk/fpdfppo_embeddertest.cpp
[modify] https://crrev.com/957480c17682008ae2a14723868fcdcab89b6577/core/fpdfapi/edit/cpdf_creator.cpp
[add] https://crrev.com/957480c17682008ae2a14723868fcdcab89b6577/testing/resources/zero_length_stream.in

This is fixed in PDFium and should roll into Chrome in the next few hours. Once it's been verified on Canary we can look to roll into M59 and M60 branches.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-59; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-59 label, otherwise remove Merge-TBD label. Thanks.

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

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

 Issue 730092  has been merged into this issue.

fix looks good in canary. As confirmed, fix is also safe and well tested. Approving merge for M59 and M60. 

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

commit 0c17bdac6ce07754402385720d3a0e70ce179949
Author: Dan Sinclair <dsinclair@chromium.org>
Date: Wed Jun 14 19:27:06 2017

[Merge M59] Allow zero length streams when parsing.

It's possible to create a stream of length 0 in a PDF document.
Currently the code will early exit and return a nullptr. This causes
issues when you want to print the given PDF as the FPDF_ImportPages code
ends up only generating up to the zero length object.

This CL allows creating streams with length 0 and updates the PDF saving
code to output a blank stream.

Bug:  chromium:732380 
Change-Id: I44182ba4aaac7c51284b002ba01bbc34b6bcf9e0
Reviewed-on: https://pdfium-review.googlesource.com/6490
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: dsinclair <dsinclair@chromium.org>
(cherry picked from commit 957480c17682008ae2a14723868fcdcab89b6577)
Reviewed-on: https://pdfium-review.googlesource.com/6556
Reviewed-by: Nicolás Peña <npm@chromium.org>

[add] https://crrev.com/0c17bdac6ce07754402385720d3a0e70ce179949/testing/resources/zero_length_stream.pdf
[modify] https://crrev.com/0c17bdac6ce07754402385720d3a0e70ce179949/testing/embedder_test.h
[modify] https://crrev.com/0c17bdac6ce07754402385720d3a0e70ce179949/core/fpdfapi/parser/cpdf_syntax_parser.cpp
[modify] https://crrev.com/0c17bdac6ce07754402385720d3a0e70ce179949/testing/embedder_test.cpp
[modify] https://crrev.com/0c17bdac6ce07754402385720d3a0e70ce179949/fpdfsdk/fpdfppo_embeddertest.cpp
[modify] https://crrev.com/0c17bdac6ce07754402385720d3a0e70ce179949/core/fpdfapi/edit/fpdf_edit_create.cpp
[add] https://crrev.com/0c17bdac6ce07754402385720d3a0e70ce179949/testing/resources/zero_length_stream.in

 Issue 733239  has been merged into this issue.

@dsinclair, what timeframe are we looking at for roll out to the main browser?

The change has been merged into both the stable and beta branches. So, whenever the next version of those is released the fix should be included.

This is already merged on to Stable (#27),approved for Beta also. So please merge to branch 3112 ASAP.

re: comment 29 - For Chrome 59, it's in 59.0.3071.103 and newer. I don't have an exact date for when the roll out will occur for any particular install.

Ping for #31, planning to have a Beta release early next week.

This was merged into branch 3112 last Wednesday (Jun 14th)[1]. I don't know why the bugdroid didn't update the bug.


1 - https://pdfium.googlesource.com/pdfium/+/chromium/3112