4

Chrome (and other WebKit rendering engines) generate seemingly inexplicable whitespace on print. Code is in CodePen link but easier to explain with pictures:

enter image description here


ACTUAL results on print from chrome (screenshot of print view):

enter image description here

Also, it does seem OL with "Default" margins set, but I don't understand the behavior without them, "default":


enter image description here

@page {
   size: 320mm 120mm;
   margin: 10mm;
   padding: 0;
   border: none;
   border-collapse: collapse; 
}

http://codepen.io/anon/pen/obqLyy

Another example of random whitespace (full html, can copy directly into notepad or whatever): http://pastebin.com/wUXsqWae

If the question seems vague, it's: "Why is there whitespace on the bottom and the right of the image when trying to print with no margins?"

Edit: So, I tested a bit, and it seems that elements don't cover the body entirely, the borders are NOT behaving as expected given the box model:

enter image description here

enter image description here

This almost solves my problem, but I have seen the issue with border-collapse before - I have no idea what it's doing here and would love to know.

Edit: Restarted my computer, now the extra body space in the last image is on the right instead of the bottom. This is pretty silly.

VSO
  • 11,546
  • 25
  • 99
  • 187
  • @Wouter: Thanks for the edit - the funny thing is that in Chrome, it's on the right, but if I run it through a WebKit html-->Pdf generator, it's on the left (WkHtmlToPdf). Really just looking for an answer that works in Chrome though. – VSO Jan 27 '16 at 21:25
  • 1
    Fixed the direction to reflect the arrows on your screenshot. – huysentruitw Jan 27 '16 at 21:50
  • You are absolutely correct. – VSO Jan 27 '16 at 21:57
  • This probably isn't worth posting as a full answer, but FWIW my testing on OSX reveals that Chrome supports `@page {size:landscape}` but not specific page sizes; Safari and Firefox appear to ignore the size rule completely. Based on the other answers it appears like the situation is less dire in windows, but if cross-platform is relevant to you, well, there's that. – Daniel Beck Jan 27 '16 at 22:08
  • @DanielBeck Thanks, I am actually throwing this html into WkHtmlToPdf in .NET, and showing the output PDF file in the browser (or providing it fl dl), so that solves the compatability issues. Chrome print seems to be rendering exactly like WkHtml is though, which is why I am using it as an example. Not sure you wanted that much detail, but wanted to reply since you took the time. – VSO Jan 27 '16 at 22:12

2 Answers2

4

An explanation to the borders appearing:

  • Your div is 280mm x 80mm in size. The proportion (280/80) is 3.5.
  • Your page is 320mm x 120mm in size. The proportion (320/120) is 2.67.

When you ask Chrome to remove the margins from your page, you end up with a div with the same size and proportions (3.5) and a scaled down page that attempts to fit the div in, but the size of the page is still of a 2.67 proportion. This explains the margins that magically appear.

I'm working on a way to solve this right now, but this should set you on the right track. Good luck!

Update

Rather read update #2.

Created a pastebin applying what I explained up there: http://pastebin.com/48RqpBFV I added 1mm to your page size (now it's 102mm) because: Body size: 99/74 = 1,33784 But page size: 101/ 76 =/= 1,33784 Adding this 1mm to your page width fixed the borders.

Update #2

http://pastebin.com/Dq837cXp Final pastebin with your second model. I used the following fixes:

@page {
   size: 101.6mm 76mm;
   padding: 0;
   margin:1mm;
   border: none;
   border-collapse: collapse;
}

And added max-height:100%; to .reportBody. It's surprising that you can actually add more digits to millimiters. 101.6mm makes it exactly the proportions you want it to be, and max-height:100%; prevents Chrome from making another page.

fnune
  • 5,256
  • 1
  • 21
  • 35
  • Thanks for the reply, I am thinking about it now. Edit: Not sure if you saw the previous edit, ignore it if you did. I am mainly interested in the overall logic here, which you are helping with. – VSO Jan 27 '16 at 22:05
  • 1
    Added a solution which I think is pretty much final! – fnune Jan 27 '16 at 22:16
  • Thanks for looking at it. Looks like this is as much of a reply as we are going to figure out. I kept messing with it, but even setting ratios correctly doesn't seem to work. What I found that if I set body and child div or table exactly the same size, they don't come out the same size in pixels, even though the "Computed" value in debugger shows they are both calculated from, say, 100mm. It's weird. – VSO Jan 29 '16 at 14:03
  • Yes I had the same thing. That's why I had to test and add .1mm in steps to finally find something that worked. I suspect this might be Chrome strangely converting `mm` from CSS into "real life" `mm` in a different way for each tag (`body`, and `divs` for example). Sorry I couldn't look into it a bit more. – fnune Jan 29 '16 at 14:08
  • 1
    It's all good - I genuinely appreciate it. I worked around it, I don't think it's worth spending more of anyone's time on, was good to get a second opinion. – VSO Jan 29 '16 at 14:13
1

I adjusted the size of the .reportTable by a couple of mm and the extra whitespace was eliminated from the print preview in Chrome.

Before: Print preview in Chrome with extra white space

After: Print preview in Chrome without extra white space

.reportTable {
    width: 99mm; /* was 97mm */
    height: 74mm; /* was 72mm */
    padding: 0;
    margin: 0;
    border: 1mm solid;
    border-collapse: collapse;
    background-color:red;
}

It looks like the table was not taking up the whole area that was set by the body and the extra space was being made visible by the browser. Perhaps a Chrome feature?

SunSparc
  • 1,812
  • 2
  • 23
  • 47
  • I appreciate the reply, We came to the same conclusion, but it doesn't seem to make sense to me. – VSO Jan 27 '16 at 22:09
  • 1
    I have in the past tried to figure out the reasoning behind certain `html/css` quirks, usually with no success. It may have to be enough just to find a workaround without actually understanding the problem. The `html/css` world is filled with quirks that come and go with each version. The answers are likely hidden deep inside the browser rendering engine code. I know that is not an answer, but there may not actually be a good answer here. – SunSparc Jan 27 '16 at 22:16