New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Huge Font Size Difference Between 0.12.3 and 0.12.4 #3241

Closed
khkremer opened this Issue Dec 8, 2016 · 78 comments

Comments

Projects
None yet
@khkremer

khkremer commented Dec 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Dec 9, 2016

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@khkremer

khkremer 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).

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

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Dec 9, 2016

Member

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?

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

This comment has been minimized.

Show comment
Hide comment
@khkremer

khkremer Dec 9, 2016

Yes, I hava retina MacBook Pro.

khkremer commented Dec 9, 2016

Yes, I hava retina MacBook Pro.

@pvandertak

This comment has been minimized.

Show comment
Hide comment
@pvandertak

pvandertak Dec 9, 2016

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?

pvandertak commented Dec 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Dec 10, 2016

Member

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?

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

This comment has been minimized.

Show comment
Hide comment
@khkremer

khkremer Dec 10, 2016

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

khkremer commented Dec 10, 2016

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

@khkremer

This comment has been minimized.

Show comment
Hide comment
@khkremer

khkremer Dec 10, 2016

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 commented Dec 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@khkremer

khkremer Dec 11, 2016

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

khkremer commented Dec 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@inferiorhumanorgans

inferiorhumanorgans Dec 13, 2016

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)

inferiorhumanorgans commented Dec 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@shoantel

shoantel Dec 13, 2016

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

shoantel commented Dec 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@inferiorhumanorgans

inferiorhumanorgans Dec 13, 2016

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

inferiorhumanorgans commented Dec 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Dec 14, 2016

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@chrisbranson

chrisbranson Dec 15, 2016

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.

chrisbranson commented Dec 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Dec 16, 2016

Member

@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...

Member

ashkulz commented Dec 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@chrisbranson

chrisbranson Dec 16, 2016

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

chrisbranson commented Dec 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@inferiorhumanorgans

inferiorhumanorgans Dec 19, 2016

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.

inferiorhumanorgans commented Dec 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@samuelcolvin

samuelcolvin Dec 20, 2016

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.)

samuelcolvin commented Dec 20, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Jan 10, 2017

Member

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

Member

ashkulz commented Jan 10, 2017

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

@AlJohri

This comment has been minimized.

Show comment
Hide comment
@AlJohri

AlJohri May 9, 2018

looks like @ashkulz is saying we might have a new release by around may 15 which fixes this regression if I'm not mistaken #3850 (comment)

AlJohri commented May 9, 2018

looks like @ashkulz is saying we might have a new release by around may 15 which fixes this regression if I'm not mistaken #3850 (comment)

@ashkulz

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz May 9, 2018

Member

I haven't gotten around to release the -rc yet, planning to do that this weekend instead.

Member

ashkulz commented May 9, 2018

I haven't gotten around to release the -rc yet, planning to do that this weekend instead.

@tkyol

This comment has been minimized.

Show comment
Hide comment
@tkyol

tkyol May 16, 2018

Any news on that fix @ashkulz?

tkyol commented May 16, 2018

Any news on that fix @ashkulz?

@ashkulz

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz May 17, 2018

Member

Working on the macOS build, definitely should be done by Saturday.

Member

ashkulz commented May 17, 2018

Working on the macOS build, definitely should be done by Saturday.

@tkyol

This comment has been minimized.

Show comment
Hide comment
@tkyol

tkyol commented May 17, 2018

awesome @ashkulz

@welsby

This comment has been minimized.

Show comment
Hide comment
@welsby

welsby May 21, 2018

Just hit the same issue, glad to know it's a known issue. Will hold fire until the next release.

welsby commented May 21, 2018

Just hit the same issue, glad to know it's a known issue. Will hold fire until the next release.

@ashkulz

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz May 21, 2018

Member

so, I've got a build but I need volunteers who will test it, preferably on older macOS versions. Anyone?

Member

ashkulz commented May 21, 2018

so, I've got a build but I need volunteers who will test it, preferably on older macOS versions. Anyone?

@geoidesic

This comment has been minimized.

Show comment
Hide comment
@geoidesic

geoidesic May 21, 2018

Mac OS X v10.12.6.. happy to test if there are clear instructions for installation (I've previously used homebrew, which is at v0.12.4)

geoidesic commented May 21, 2018

Mac OS X v10.12.6.. happy to test if there are clear instructions for installation (I've previously used homebrew, which is at v0.12.4)

@lkraider

This comment has been minimized.

Show comment
Hide comment
@lkraider

lkraider May 21, 2018

@ashkulz please send me a copy, I am on macOS 10.11.6 and might be able to test on 10.9 as well.

lkraider commented May 21, 2018

@ashkulz please send me a copy, I am on macOS 10.11.6 and might be able to test on 10.9 as well.

@ashkulz

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz May 22, 2018

Member

Sorry for the delay. I've been porting to a new vagrant-based build system which would ensure that anyone can easily create builds if required.

So where I got stuck is that I'm statically linking to OpenSSL (as the macOS OpenSSL is 0.9.8z, which is too old) and it is supposed to require manually creating a cert bundle -- but it was working without it. I thought that it was something to do with my dev setup, so tried creating VMs for 10.9 and 10.7 -- wkhtmltopdf builds but doesn't run there as the GUI doesn't seem to start on those VMs (maybe the template needs tweaking?).

So I need testing input whether the builds will actually work on real hardware or VM with GUI, as there's no way I can seem to check that.

  • Please test both the 32-bit (carbon) and 64-bit (cocoa) build from https://builds.wkhtmltopdf.org/0.12.5-dev/ -- just untar and run wkhtmltox/bin/wkhtmltopdf
  • Check it on SSL sites e.g. Github itself
  • Check it on local intranet sites with certificates installed in Keychain (i.e. CA wouldn't be known to OpenSSL)
  • Check it for this issue (obviously)

I did a test on a laptop with macOS 10.12, seems to work fine but not sure where the certificates are coming from -- don't want to release something that might fail later. Will work on building as a .pkg later on once I get confirmation that these builds work.

Member

ashkulz commented May 22, 2018

Sorry for the delay. I've been porting to a new vagrant-based build system which would ensure that anyone can easily create builds if required.

So where I got stuck is that I'm statically linking to OpenSSL (as the macOS OpenSSL is 0.9.8z, which is too old) and it is supposed to require manually creating a cert bundle -- but it was working without it. I thought that it was something to do with my dev setup, so tried creating VMs for 10.9 and 10.7 -- wkhtmltopdf builds but doesn't run there as the GUI doesn't seem to start on those VMs (maybe the template needs tweaking?).

So I need testing input whether the builds will actually work on real hardware or VM with GUI, as there's no way I can seem to check that.

  • Please test both the 32-bit (carbon) and 64-bit (cocoa) build from https://builds.wkhtmltopdf.org/0.12.5-dev/ -- just untar and run wkhtmltox/bin/wkhtmltopdf
  • Check it on SSL sites e.g. Github itself
  • Check it on local intranet sites with certificates installed in Keychain (i.e. CA wouldn't be known to OpenSSL)
  • Check it for this issue (obviously)

I did a test on a laptop with macOS 10.12, seems to work fine but not sure where the certificates are coming from -- don't want to release something that might fail later. Will work on building as a .pkg later on once I get confirmation that these builds work.

@ashkulz

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz May 22, 2018

Member

@lkraider @geoidesic: any feedback? Back in the day, @mn4367 had helped test out various mac environments.

Member

ashkulz commented May 22, 2018

@lkraider @geoidesic: any feedback? Back in the day, @mn4367 had helped test out various mac environments.

@mb21

This comment has been minimized.

Show comment
Hide comment
@mb21

mb21 May 22, 2018

@ashkulz wkhtmltopdf https://github.com/ foo.pdf works for both carbon and cocoa versions.

For this issue, see the attached PDFs, generated from the test.txt attached in the first post of this issue:
0-12-3.pdf
0-12-5-dev-carbon.pdf
0-12-5-dev-cocoa.pdf

Assuming that the 0-12-3.pdf has the right size, the other ones have a bit too small a font size (also, the line-height seems to slightly differ between the carbon and cocoa versions..)

Note that I'm on a retina-MacBook Pro on macOS 10.13.4
(and I get the same result with an external non-retina screen connected, but not sure how that works out, because I guess it would depend on which screen the invisible window is on...)

mb21 commented May 22, 2018

@ashkulz wkhtmltopdf https://github.com/ foo.pdf works for both carbon and cocoa versions.

For this issue, see the attached PDFs, generated from the test.txt attached in the first post of this issue:
0-12-3.pdf
0-12-5-dev-carbon.pdf
0-12-5-dev-cocoa.pdf

Assuming that the 0-12-3.pdf has the right size, the other ones have a bit too small a font size (also, the line-height seems to slightly differ between the carbon and cocoa versions..)

Note that I'm on a retina-MacBook Pro on macOS 10.13.4
(and I get the same result with an external non-retina screen connected, but not sure how that works out, because I guess it would depend on which screen the invisible window is on...)

@geoidesic

This comment has been minimized.

Show comment
Hide comment
@geoidesic

geoidesic May 22, 2018

Carbon version works for me on Mac OS X v10.12.6
test2.pdf

Cocoa version works for me on Mac OS X v10.12.6
test.pdf

Also tested in my app and it looks fine. I'm probably not being as picky as @ashkulz – I didn't compare it that closely. It's a huge improvement anyway.

geoidesic commented May 22, 2018

Carbon version works for me on Mac OS X v10.12.6
test2.pdf

Cocoa version works for me on Mac OS X v10.12.6
test.pdf

Also tested in my app and it looks fine. I'm probably not being as picky as @ashkulz – I didn't compare it that closely. It's a huge improvement anyway.

@Lazza

This comment has been minimized.

Show comment
Hide comment
@Lazza

Lazza May 22, 2018

@geoidesic is your display "retina"?

Lazza commented May 22, 2018

@geoidesic is your display "retina"?

@geoidesic

This comment has been minimized.

Show comment
Hide comment
@geoidesic

geoidesic May 22, 2018

@Lazza Yes it is retina. (2880 x 1800)

geoidesic commented May 22, 2018

@Lazza Yes it is retina. (2880 x 1800)

@lkraider

This comment has been minimized.

Show comment
Hide comment
@lkraider

lkraider May 24, 2018

@ashkulz I have created some test scripts: test-scripts.zip

It tries rendering with different DPI settings, and also different SSL websites:

I ran both the carbon and cocoa builds on two systems:

System 1

mac-air$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.11.6
BuildVersion:	15G19009

System 2

mac-mini$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.9.5
BuildVersion:	13F1911

Both produced similar results and the same issues were encountered:

  • Font size differs between Carbon and Cocoa builds
  • Font size differs between DPI options (even using --disable-smart-shrinking option)
  • Both self signed or custom CA render the page (whether the CA is installed in the login keychain or not), but seems that some referenced files fail to load correction: I think I was confusing css media, since generated pdf output differs from browser

Sample cocoa build output difference, for comparison on DPI setting output:

test-dpi-scale-cocoa-72dpi-0.12.5.pdf
test-dpi-scale-cocoa-96dpi-0.12.5.pdf

Attached are the result files and full run logs. Let me know if more info is required.

  1. results-system1.zip
  2. results-system2.zip

lkraider commented May 24, 2018

@ashkulz I have created some test scripts: test-scripts.zip

It tries rendering with different DPI settings, and also different SSL websites:

I ran both the carbon and cocoa builds on two systems:

System 1

mac-air$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.11.6
BuildVersion:	15G19009

System 2

mac-mini$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.9.5
BuildVersion:	13F1911

Both produced similar results and the same issues were encountered:

  • Font size differs between Carbon and Cocoa builds
  • Font size differs between DPI options (even using --disable-smart-shrinking option)
  • Both self signed or custom CA render the page (whether the CA is installed in the login keychain or not), but seems that some referenced files fail to load correction: I think I was confusing css media, since generated pdf output differs from browser

Sample cocoa build output difference, for comparison on DPI setting output:

test-dpi-scale-cocoa-72dpi-0.12.5.pdf
test-dpi-scale-cocoa-96dpi-0.12.5.pdf

Attached are the result files and full run logs. Let me know if more info is required.

  1. results-system1.zip
  2. results-system2.zip
@ashkulz

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz May 24, 2018

Member

Okay, thanks for the detailed testing! It looks like OpenSSL is somehow getting root certificates, as it warns on self-signed or custom CA (maybe getting bundled in the build process?) -- needs investigation.

With respect to the size difference, the DPI was standardized/hard-coded to 96 across all platforms in the PR linked above -- earlier it was 72, so some amount of "shrinking" is expected (this was a complaint of linux users as well, where it too was 72 earlier). Using --dpi is unlikely to have an impact on output.

The carbon builds are not really required and I was going to drop them for this release (not supported in Qt5) but because I built a 10.7 configuration for the OpenSSL testing I've kept it going -- Apple has deprecated it long back and there's no way I can fix issues with it.

I'll need to examine the testcases by @lkraider in more detail, will do that this weekend.

Member

ashkulz commented May 24, 2018

Okay, thanks for the detailed testing! It looks like OpenSSL is somehow getting root certificates, as it warns on self-signed or custom CA (maybe getting bundled in the build process?) -- needs investigation.

With respect to the size difference, the DPI was standardized/hard-coded to 96 across all platforms in the PR linked above -- earlier it was 72, so some amount of "shrinking" is expected (this was a complaint of linux users as well, where it too was 72 earlier). Using --dpi is unlikely to have an impact on output.

The carbon builds are not really required and I was going to drop them for this release (not supported in Qt5) but because I built a 10.7 configuration for the OpenSSL testing I've kept it going -- Apple has deprecated it long back and there's no way I can fix issues with it.

I'll need to examine the testcases by @lkraider in more detail, will do that this weekend.

@ashkulz

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz May 30, 2018

Member

A release candidate is available which includes the fixes mentioned above -- please test and report your findings before the final release (other than the font size differences, which are a known change due to standardizing the DPI to 96).

Member

ashkulz commented May 30, 2018

A release candidate is available which includes the fixes mentioned above -- please test and report your findings before the final release (other than the font size differences, which are a known change due to standardizing the DPI to 96).

@suryart

This comment has been minimized.

Show comment
Hide comment
@suryart

suryart May 31, 2018

Running Mac OSX 10.13.4: Ran RC release and I can confirm that font size is back to normal and HTML is being converted to pdf as expected. Thanks.

suryart commented May 31, 2018

Running Mac OSX 10.13.4: Ran RC release and I can confirm that font size is back to normal and HTML is being converted to pdf as expected. Thanks.

@lkraider

This comment has been minimized.

Show comment
Hide comment
@lkraider

lkraider May 31, 2018

Release candidate seems to be working as expected here!

lkraider commented May 31, 2018

Release candidate seems to be working as expected here!

@algodave

This comment has been minimized.

Show comment
Hide comment
@algodave

algodave Jun 6, 2018

I'm on a MacBook Pro (Retina, 15-inch, Late 2013) with OSX 10.11.6 and wkhtmltopdf 0.12.4 (with patched qt) installed with brew install homebrew/cask/wkhtmltopdf.

While waiting for 0.12.5, I'm passing --lowquality option and I'm getting PDFs with expected font sizes. Hope this helps someone else!

algodave commented Jun 6, 2018

I'm on a MacBook Pro (Retina, 15-inch, Late 2013) with OSX 10.11.6 and wkhtmltopdf 0.12.4 (with patched qt) installed with brew install homebrew/cask/wkhtmltopdf.

While waiting for 0.12.5, I'm passing --lowquality option and I'm getting PDFs with expected font sizes. Hope this helps someone else!

@lucabusin

This comment has been minimized.

Show comment
Hide comment
@lucabusin

lucabusin Jul 3, 2018

I am just leaving this here for those who come here in my same situation.
I have originally created my reports on a Ubuntu 12 on EC2 with 0.12.3. I have now upgraded to Ubuntu 16.04 with 0.12.5 and found that specifying dpi 75 and zoom 1.28 (i.e. 96/75) produces almost identical output.

lucabusin commented Jul 3, 2018

I am just leaving this here for those who come here in my same situation.
I have originally created my reports on a Ubuntu 12 on EC2 with 0.12.3. I have now upgraded to Ubuntu 16.04 with 0.12.5 and found that specifying dpi 75 and zoom 1.28 (i.e. 96/75) produces almost identical output.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment