Huge Font Size Difference Between 0.12.3 and 0.12.4 #3241

Open
khkremer opened this Issue Dec 8, 2016 · 19 comments

Projects

None yet

7 participants

@khkremer
khkremer commented Dec 8, 2016 edited

This is a comparison between the output created by the Mac OS X version of 0.12.3 and 0.12.4 - I consider what I see with 0.12.3 the correct output.

I am running the software on Mac OS X 10.11.6

This test was done using these builds downloaded from the official web site:

wkhtmltox-0.12.3_osx-cocoa-x86-64.pkg
wkhtmltox-0.12.4_osx-cocoa-x86-64.pkg

I use a very simple HTML file that only contains a few headers from h1 to h3 plus some lorem ipsum sample text in p tags.

The HTML file was converted using no command line options besides the input and the output file:

wkhtmltopdf test.html test.pdf

Here is the sample HTML file (renamed to .txt to be able to attach it):
test.txt

And here are the two output files created by the two different wkhtmltopdf versions:
test_0.12.3.pdf
test_0.12.4.pdf

The paragraph text in the 0.12.3 version if about 12.3pt in size, whereas the 0.12.4 version creates 3.07pt text. It seems that all text is by a factor of 4 too small.

This may be related to the other "font size is too small" problems, but what I am seeing seems to be much more extreme than anything else I've found so far.

@ashkulz
Member
ashkulz commented Dec 9, 2016

Hmm, looks like it may be a regression due to #2463 by @pvandertak. Can you check if using different values for --dpi helps?

@khkremer
khkremer commented Dec 9, 2016

You are spot on: When I change the DPI value using the --dpi switch, the font size changes. Attached are a number of different files.

test_4_300dpi.pdf
test_4_360dpi.pdf
test_4_380dpi.pdf
test_4_400dpi.pdf
test_4_600dpi.pdf

The version using 380dpi is getting close to what I would expect.

The only elements in a PDF file that should be rendered differently based on a resolution are images, text and vector graphic don't have an inherent resolution (hence the "portable" in the PDF format name).

@ashkulz
Member
ashkulz commented Dec 9, 2016

Ideally, #2463 would have resulted in a consistent DPI being used across platforms. I don't have access to a Mac so can't really test anything before a release. Considering that 380 ~ 96*4, are you running in HiDPI/retina mode or something like that?

@khkremer
khkremer commented Dec 9, 2016

Yes, I hava retina MacBook Pro.

@pvandertak

What if you specify the font size explicitly? Now, the size depends on the browser's defaults (see e.g. http://stackoverflow.com/questions/6140430/what-are-the-most-common-font-sizes-for-h1-h6-tags ; I'm not sure what wkhtmlpdf does). Maybe the default depends on the dpi/zoom factor on retina or something like that?

If you use something like:

<div style="width: 1in; height: 1in; background: red;"></div>

Does it show up as one inch or stretched depending on the DPI?

@ashkulz
Member
ashkulz commented Dec 10, 2016

I suspect that when we discarded the zoomFactor, this got lost as well. @khkremer: Can you confirm if it works OK on a non-retina mac?

@khkremer

I will have to fine one... Give me a day or two.

@khkremer

This is what I get with the 1" square test without specifying a resolution. When I do use the --dpi option, the square gets scaled just like the text:

2016-12-10_11-14-19

The rulers left and top are from Adobe Acrobat and show size in inches. As you can see, the square is well below one square inch in size.

@khkremer

I ran the test on a MacMini with a regular non-retina display, and I get pretty much the same result, the only difference is that the margin at the top seems to be different. I've added some guides in Acrobat to show this effect. The font sizes are identical, and the size of the square also seems to be identical between both versions. The labels "non-Retina" and "Retina" were added just to the screenshot image, they are not part of the original PDF file. Units for the rulers are again set to inches.

2016-12-11_09-57-41

2016-12-11_09-57-03

@inferiorhumanorgans
inferiorhumanorgans commented Dec 13, 2016 edited

Scaling is very much broken on my high-DPI non-retina mac (1680x1050 MacBook Pro).

<html>
  <body style="font-size: 10pt; margin: 0; padding: 0;">
    <div style="border: 1px solid black; width: 8.25in; top: 0.25in; left: 0in; height: 1in; position: absolute">
      test
    </div>
  </body>
</html>

When run with:

wkhtmltopdf --disable-smart-shrinking -s letter -B 0 -L 0 -R 0 -T 0 test.html test.pdf

The output is way off.

$ uname -v
Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64
$ wkhtmltopdf --version
wkhtmltopdf 0.12.4 (with patched qt)
@shoantel

Seeing the same problem. Have v0.12.4 64-bit on maOS 10.12.1. Darwin Kernel Version 16.1.0: Thu Oct 13 21:26:57 PDT 2016; root:xnu-3789.21.3~60/RELEASE_X86_6 // wkhtmltopdf 0.12.4 (with patched qt).

PDF that used to work went from 106 pages down to 11 and tiny text. Using an extra '--dpi 765' seems to fix the issue. I note the adjustment is >x2 the setting needed above by @khkremer

@inferiorhumanorgans

Last night using --dpi 300 worked for me. I upgraded some other things and suddenly I had to add --zoom 2.

@ashkulz ashkulz added the Verified label Dec 14, 2016
@ashkulz
Member
ashkulz commented Dec 14, 2016

Can someone please summarize what value of --dpi works for them and gets back the output as in 0.12.3?

@chrisbranson

I've also noticed a size difference between 0.12.3 and 0.12.4 on Linux - not as dramatic as on a Mac, but enough to mean that all the HTML docs we produce in our app are now rendered smaller.

Using the test HTML given at the top of this issue, here's the resulting PDF using the 0.12.3 version we currently use and 0.12.4 as released -

test_linux_0.12.3.pdf
test_linux_0.12.4.pdf

I've tried adjusting the dpi, with no effect - I've also tried adjusting the zoom level but this doesn't get me back to a matching output as per 0.12.3.

@ashkulz
Member
ashkulz commented Dec 16, 2016 edited

@chrisbranson: That's absolutely expected, the main reason for the change was to get the DPI standardized across all supported platforms to 96 DPI (earlier default for Linux was 72 dpi). Unfortunately, I don't have a Mac and hence this regression..

Does changing the DPI have absolutely no effect? That's strange...

@chrisbranson

I've tried changing the dpi with a wide range of values, but the output essentially remains the same (there are very small differences). Note, this is using the Linux build on an Amazon Linux EC2 instance.

I use the command wkhtmltopdf --dpi 72 http://google.com google-0.12.4-dpi-72.pdf to vary the dpi but the output is little different to the default output.

google-0.12.4-dpi-72.pdf
google-0.12.4.pdf

The same page generated on the same server, but with 0.12.3: -
google-0.12.3.pdf

@inferiorhumanorgans

Yeah this is consistently inconsistent. If I'm using my computer on one network I need to set DPI=300 and zoom=2. On another network DPI=300 and zoom=1.

@samuelcolvin

Had the same issue after I upgraded pydf to use wkhtmltopdf 0.12.4.

The following change were required to get pdfs and html pdf previews looking both smart and consistent:

  • zoom changed from 1.04 to 1.25
  • using the https://fonts.googleapis.com/css?family=Roboto:300,400 font I need to use font-weight: 300 for pdf rendering and font-weight: 400 in the preview. (I don't think this was a change with 0.12.4, I just hadn't got round to fixing it before).

PDF:
image

Preview:
image

Not identical but I think pretty impressive of wkhtmltopdf to get this close.

(Both testing and production are on Ubuntu.)

@ashkulz
Member
ashkulz commented Jan 10, 2017 edited

I've documented this regression on the downloads page in e6ac642.

@ashkulz ashkulz added the Regression label Jan 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment