wkhtmltopdf css sizes in cm/mm

Question

I use wkhtmltopdf to produce A4 sized PDFs. When I create a <div> tag and set its style to height: 297mm; width: 210mm (which is the defined size of A4), set wkhtmltopdf's margin settings to 0 (wkhtmltopdf -B 0 -T 0 -L 0 -R 0 ...) and give the <div> a red background, I can see a thin white line at the bottom of the page, i.e. the <div> is not filling the page completely. This is happening consistently with 0.11.0 rc1 (the latest version) on Debian and with 0.10.0 rc2 on Mac OS X.

Has anyone else seen this? Is this a known problem, or is there a workaround?

Fruiterer

I have experienced this consistently as well and would Love to see a solution. – Schoolbook

I have experienced something similar on the latest version, running CentOS. – Grindstone

I too am experiencing this issue. – Tehee

I had the same problem, trying to produce an 8.5x11 inch document. I switched my command to Letter instead of A4 and that did it - also I adjusted my container to 215.9mm × 279.4mm. Let me know if it works for you? – Tehee

Well, Letter and A4 are two different sizes, and the first thing I did try was page-size A4 and 210mm x 297mm... it's intersting to know, though, that Letter seems to work properly. – Fruiterer

A way to debug wkhtmltopdf is to download Qt web browser and see if that white line still appears in the browser. – Sheave

Use the --disable-smart-shrinking flag, see my answer – Kraft

Answer 1

I had a method that worked for me that used margins.

style="margin:0,auto"

If that doesn't work try:

style="margin:0,auto,0,auto"

Motion

Answer 2

There is this flag for wkhtmltopdf: --disable-smart-shrinking - when you use this, the dimensions are resolved as given, so A4 will be almost 210mm x 297mm like expected.

However, over the course of ~40+ pages, it seems a height of 297.25mm is safe.

wkhtmltopdf -L 0 -R 0 -T 0 -B 0 -s A4 --disable-smart-shrinking doc.html doc.pdf

Without using it, so with this magical smart shrinking enabled, a full A4 page for me is

{
  width: 991px;
  height: 1403px;
}

or

{
  width: 262.2mm;
  height: 371.25mm;
}

Tested with 33 pages of that size

Kraft

Answer 3

Perhaps try increasing the height of the <div> a fraction of a mm?

height: 297.5mm or height: 298mm instead?

Let me know if that works.

Katalin

Answer 4

Try set <div> element style="margin: 0;" in my case this helps...

Buddie

Answer 5

Don't know if it helps, but after some tries (border red on a div), I figured that the wkhtmltopdf default A4 page is about 1000px wide, and 1425px tall.

Gannie

Thanks, this helped! I will formulate it in a full answer – Kraft

Answer 6

Default for A4 will be dependant of getting metric sheet ratios correct, and sadly there are too many wrong answers.

default as px will naturally be rounded off in applications as px should be integers thus unreal

A4 as pixels based on a (incorrect assumption there are a fixed number of 96 per inch)

  width: 793.701px;
  height: 1122.52px; 

QT Web Kit uses 160dpi thus it will work with

body {
  border: 0;
  margin: 0;
  padding: 0;
  width: 992.126px;
  height: 1403.15px; 
}
.myDiv {
  border: 5px outset red;
  background-color: lightblue;    
  text-align: center;
  height: 1393.15px;
}

Ideally the Media when printing should also be set

    <style>
@media print {
@page { size: 210mm,297mm; }
}
body {

The big issue is the use of WebKit scale by default

--enable-smart-shrinking
Enable the intelligent shrinking strategy
used by WebKit that makes the pixel/dpi
ratio non-constant (default)

This means that for A4 wide @100% we need a different value and from trial and error you may find this works

body {
  border: 0;
  margin: 0;
  padding: 0;
}
.myDiv {
  background-color: red;    
  text-align: center;
  width: 100%;
  height: 1052.9pt;
}

So for HTML graphics like these where 96 is the norm we need to add an over-ride --disable-smart-shrinking

And the correct ratio and scale will be used

wkhtmltopdf.exe  -B 0 -T 0 -L 0 -R 0 -s A4 --disable-smart-shrinking red.htm red.pdf

And the result should be perfect.

A Secondary problem is different browsers use different rounding off strategy when determining PDF units, thus the value for FireFox may need a small adjustment for Chromium! and visa versa!

Hankhanke