Why do wkhtmltopdf.exe produce different results on different Windows machines?

Question

I have a simple test.html file:

<html>
<div style="width: 100%; font-size: 28pt;">
This is a test to see what happens when this kind of text gets processed by wkhtmltopdf
</div>
</html>

Which I run through wkhtmltopdf.exe like this:

wkhtmltopdf.exe test.html test.pdf

On one machine I get the following result:

But on another machine I get this result:

It looks like the font size is different?

Why is this happening?

Thanks.

EDIT

I found out what causes this. Windows has a setting for changing the text size:

For some reason the default on one computer is 100% and on the other it is 125%. Are there any way to ignore this in webkit?

@AShelly I found out that the text size in windows was different, I edited the question. — smerlung, Jun 03 '14 at 15:51
You can post the solution as an answer and accept it to help others. — AShelly, Jun 03 '14 at 16:03
Yes but I don't think is a real solution, only a work around. I can't force users to have a specific setting in their windows setup. — smerlung, Jun 03 '14 at 16:08
No, but if I, the user, have chosen large fonts, I want large fonts. Maybe I have bad eyesight. I'll be annoyed with you if you purposely ignore my settings and make my text smaller. — AShelly, Jun 03 '14 at 16:26
That is a valid point, but not relevant in my case because the generated documents has to look the same regardless of who generates them. — smerlung, Jun 04 '14 at 07:05

smerlung · Accepted Answer · 2015-03-20T12:34:58.157

15

As I have written in the original post, the root cause of the problem is that wkhtmltopdf is affected by text size setting in windows. So in my case the two different computers has two different windows text size settings. Hopefully this information can be usefull to someone.

EDIT

It has been a while, but if anyone is interested this is how I ended up solving the problem. I used the argument:

--dpi 125

125 is not a magic number it just ended producing the best visual result in my case. I didn't have a lot of time to look into this, but it solved the problem, and now every windows machine produce the same result.

As a note --zoom argument didn't solve the discrepancy between windows machines.

edited Mar 20 '15 at 12:34

answered Jun 04 '14 at 07:09

smerlung

1,459
1
13
32

I would expect that the wkhtmltopdf switch -dpi should overwrite this? – smerlung Jun 04 '14 at 07:25
1

using version 0.12.2.4, found that --disable-smart-shrinking and --dpi options did not produce consistent output across devices. – Robb Sadler Jul 29 '15 at 14:19
Using `zoom` helped for me too – was getting different results each time I ran the same program on the same machine. – JeffThompson Jul 26 '17 at 15:52

score 9 · Answer 2 · answered Oct 02 '14 at 09:42

I found that defining --page-height and --page-width in pixels instead of mm, cm or in helps. I modified my conversion command from:

"C:\Program Files\wkhtmltopdf\bin\wkhtmltopdf.exe" --print-media-type --page-width 210 --page-height 160 --margin-top 0 --margin-right 0 --margin-bottom 0 --margin-left 0 --dpi 300 --zoom 1.043 --header-spacing 0 --footer-spacing 0 --javascript-delay 1000 html_file pdf_file

to:

"C:\Program Files\wkhtmltopdf\bin\wkhtmltopdf.exe" --print-media-type --page-width 1588px --page-height 1210px --margin-top 0 --margin-right 0 --margin-bottom 0 --margin-left 0 --dpi 150 --zoom 3 --header-spacing 0 --footer-spacing 0 --javascript-delay 1000 html_file pdf_file

The solution was tested at wkhtmltopdf 0.11.0_rc1 and 0.12.1.1, both on windows 7 x64.

Now the pdf version of the html looks identical on machines with small text size and medium text size.

score 4 · Answer 3 · answered Nov 17 '16 at 10:40

In case it helps anyone, let me share the settings that worked for me, after much expirimenting.

I'm running Windows and using --disable-smart-shrinking to have full control over the margin sizes (to fit an address behind an envelope window).

Calibri seems to generally render a lot better than Arial (besides being much prettier anyway :-)), so I've set font-family: Calibri, Helvetica, Arial, sans-serif;

I get decent results using --dpi 96.

The amount of text that fits in a row is almost 1:1 between browser and PDF. (The PDF can fit slightly more text, which is less harmful than the other way around.)

We can get even more accurate by using a zoom that we then compensate in the DPI. To use zoom 1.33 without actually getting a larger result, we need to cram 1.33 times as many dots into an inch, so 96 * 1.33 = 128 DPI. Experimenting proves that the result is slightly more accurate with 130, for whatever reason, so:

--zoom 1.33 --dpi 130

score 3 · Answer 4 · answered Mar 19 '15 at 15:05

3

set --zoom to 1.33 to compensate for the 96dpi on windows since linux is 75dpi

answered Mar 19 '15 at 15:05

Ogie

1,304
2
14
17

I have not tried it on linux. The system is only used on windows. And as I wrote in my answer: --zoom didn't solve the descrepancy between the different windows computers we use. – smerlung Mar 20 '15 at 12:36

score 0 · Answer 5 · answered Dec 17 '14 at 22:01

--disable-smart-shrinking seems to be working for me. This way I can still use mm which would otherwise be a problem since I have to use different printers.

If you use NReco, you can just use pdfconverter.CustomWkHtmlArgs = " --disable-smart-shrinking ";

Why do wkhtmltopdf.exe produce different results on different Windows machines?

5 Answers5