Attached HTML document in case jsfiddle link is removed.

Deleted: tpl4.html 3.1 KB

tpl4.html 3.1 KB View Download

May be related to https://bugs.chromium.org/p/chromium/issues/detail?id=772685, but the issue occurs with any element, not just SVGs.

JSFiddle link is wrong, please use HTML document attached above.

Correct fiddle: https://jsfiddle.net/agywqwdv/

Able to reproduce this issue on reported chrome version stable 61.0.3163.100 and on the latest canary 64.0.3241.0 using Ubuntu 14.04 and Windows 10 with steps mentioned in Comment#0.
Note: In Mac 10.12.6 issue is not seen.  

This issue is seen from M50[50.0.2634.0]. Hence treating it as non-regression and marking as untriaged.

Note that the fiddle URL in the original post is incorrect. Please use https://jsfiddle.net/agywqwdv/ or the uploaded HTML file.

I added a simplified test case showing images being clipped entirely when they overflow pages.

The second page overflows by 0.1in, and the image disappears (see clipped-image.pdf).

If 'overflow: hidden;' rule is removed from the page, then a third page is created and the image is pushed onto it (see extra-page.pdf).

Deleted: image-clip.html 661 bytes

image-clip.html 661 bytes View Download

Deleted: clipped-image.pdf 4.4 KB

clipped-image.pdf 4.4 KB Download

Deleted: extra-page.pdf 4.8 KB

extra-page.pdf 4.8 KB Download

Previous test case was printed using the following parameters:

{
  landscape:           true,
  displayHeaderFooter: false,
  printBackground:     true,
  scale:               1,
  paperHeight:         6,
  paperWidth:          4,
  marginTop:           0,
  marginLeft:          0,
  marginRight:         0,
  marginBottom:        0,
  pageRanges:          ''
}

Any progress? I've run into this with printing reports, though I was able to work around the image problem -- it's block of text that I don't have a work around for. Should the text handling be a separate issue?

Any update on this?

Sounds like a bug in printing, skia or blink.

+thestig for routing.

+chrishtr to check if this should be treated as dupe of  bug 772685 , see comment #2.

I also posted a similar bug. This one impacts any element which overlaps the wrapping page. Please see:

https://bugs.chromium.org/p/chromium/issues/detail?id=819735

I don't think it is the same as 772685, however not 100% sure.

How do I print with headless to test locally?

Hi Chris, I am using node.js with 'Remote Chrome Interface' adapter (https://github.com/cyrus-and/chrome-remote-interface). You can also use Puppeteer to achieve the same (https://github.com/GoogleChrome/puppeteer).

Would it help if I setup an executable nodejs repo?

I've setup a repo for testing Headless issues - Linux + Docker + nodejs. This might save you some time: https://github.com/soncodi/chromium-headless-printtopdf

Please let me know how I can help!

Added a test for reproduction in https://crrev.com/c/955222.

To run, build the headless_browsertests target and then:
# ./headless_browsertests --gtest_filter=*PDFOverflow*

You can trace this test using --trace-startup (to ensure the test runs long enough, simply remove the call to FinishAsynchronousTest(), which will make it time out).

As ET team do not have headless setup on Linux to test and confirm this issue as of now.. Requesting for further help in triaging this.

Thanks!

The Rendering Core team can look after the bisect and/or testing.

Tried to setup Headless on Linux by following the steps mentioned in https://github.com/soncodi/chromium-headless-printtopdf

After running this command: docker build -t headless, it asked to get docker. We used "sudo apt-get install docker" command to get it. Even after that it says docker isn't available. Attaching the screen cast of the same.

Could someone help us whether the steps followed to setup Headless are correct!

Thanks!

Deleted: 774970-print-to-pdf.mp4 3.2 MB

	774970-print-to-pdf.mp4 3.2 MB View Download

Hello,

If you have Chrome or Chromium browsers installed, it may be easier to skip Docker altogether. I've just updated the repository with additional run scripts and instructions:
https://github.com/soncodi/chromium-headless-printtopdf



To run Chrome inside Docker instead, the best option is to follow the official guide for Docker CE (https://docs.docker.com/install/linux/docker-ce/ubuntu/) instead of installing from Ubuntu repos.

Note that Docker requires superuser permissions, so you will need to prefix the run script with sudo. Alternately you can run:
sudo usermod -aG docker $USER

and logout/login to run Docker as your current user without sudo.

Issue still appears in nightly Chromium 67.0.3369.0 (64-bit)

Is this the same as 494316 ?

I'd be willing to bet it is indeed the same as 494316. Good call. That one should be easier to debug.

Not marking duplicate yet because we're not sure.

Checked the issue on latest stable 65.0.3325.162 and on 60.0.3072.0 using Ubuntu 14.04 with the below mentioned steps.
1. Downloaded the file provided in https://github.com/soncodi/chromium-headless-printtopdf
2. Unzipped the file to Documents folder
3. Opened terminal and, have run the command git clone https://github.com/soncodi/chromium-headless-printtopdf.git
4. Changed the directory to Documents
5. Then Cd chromium-headless-printtopdf-master
6. npm install
7. ./run-chrome.sh
Observed similar results in folder "Fixture" in both the above mentioned chrome versions. Attaching the screen shots of the same.  

Thanks!

Deleted: in.html.png 94.4 KB

	in.html.png 94.4 KB View Download

Deleted: out.pdf.png 98.1 KB

	out.pdf.png 98.1 KB View Download

The repro shown in the screens above is actually for another print bug I filed: https://bugs.chromium.org/p/chromium/issues/detail?id=819735

It is a very similar issue which may turn out to be a duplicate. Note that both issues can be reproduced using the github repo provided (after changing the input file).

The NextAction date has arrived: 2018-03-19

Hello, any further update? Did the repository help - should I provide additional repros?

I have a fix but it requires testing and more important things have come up.

I'll make every effort to get it into M-66.

Understood, and thank you for your help here. This issue hits our central path so anything I can do to help please let me know!

If it does not make it into M66 - would it be possible to get a dev build with the patch? Thanks again.

Hi, any chance to get a dev/nightly build with this for testing?

Sorry, still working through other regressions. I can't say when I'll get back to this, but it will be soon.

This issue and related https://bugs.chromium.org/p/chromium/issues/detail?id=819735 are impacting a large percentage of our users in production.

This is of critical priority to us. We can help with testing and infrastructure setup. Please let us know what can be done to fast-track this.

Hello, any update on this?

Best estimate right now is a fix for Chrome 69.

Issue 852652 has been merged into this issue.

phanindra.mandapaka@chromium.org -- issue 852652 merged into this one seems unrelated.

Can you also take a look at this one:

https://bugs.chromium.org/p/chromium/issues/detail?id=819735

@schenney which fixes did you think would help to resolve this bug?

I had an attempted fix but it broke some other test case that mstensho@ pointed out broke other content. https://chromium-review.googlesource.com/c/chromium/src/+/1176268

The real fix is to add struts for block level content, but that's bigger. I should un-assign myself unless we consider the other breakage less bad than this breakage, or I limit the proposed fix more tightly.