bad kerning for fonts in output PDF

[dandersson]

This is the old Issue #72 from Google Code, first reported in 2009. It still occurs with the dev branch of 0.12.0, tested with commit d6541fe .

What steps will reproduce the problem?

1. Generate PDF from any HTML input with wkhtmltopdf via e.g.

   ./wkhtmltopdf test.html test.pdf
   

2. View it. Tested with Evince, Xpdf and Chrome's built-in PDF reader with similar results.

What is the expected output? What do you see instead?
Expected: A PDF rendering similar to the one seen of the HTML document in a browser, specifically concerning the letter-spacing.

Result: The kerning is way off. Sometimes too expanded, sometimes too condensed. See attached sample rendering of (from left to right):

1. an HTML document rendered by a browser (Chrome)
2. the resulting PDF rendered by Chrome's built-in PDF reader
3. the resulting PDF rendered by Evince

What version of the product are you using? On what operating system?
Dev branch of 0.12.0, tested with commit d6541fe . Debian Sid, i386. Using the binary that resulted after building the Git revision with:

./build_linux.sh linux-i386

I have tested earlier versions of Wkhtmlpdf on Fedora (amd64) with identical results.

Please provide any additional information below.
I include the sample document and rendering below, but it happens with everything I throw to Wkhtmltopdf, so I don't think there are any specific "clues" in the minimal HTML code.

• Generated PDF (semi-stable host)
• Direct link to HTML document (semi-stable host)
• HTML document at Pastebin
• Screenshot of rendering. Best viewed in full size. Note e.g. the whitespace after the letter "o" in the PDF renderings.
• Full strace output
• strace output, grep:ed for file I/O

[ashkulz]

I don't really have a clue here, as it looks like something internal to Webkit. Can you try if using a WOFF font works? In my test with Gentium, it does look marginally better.

[ashkulz]

Can you check if you compile it yourself, it works better for you?

[xathien]

Compiled it myself using the static shell script (wkhtmltopdf version 0.12.0 2d438a3) on a CentOS 6 box and the kerning is still rather obnoxious: see attached screenshot. Of particular note is the "o" in Total. When compiled on my Fedora machine, the problem is significantly reduced.

Left side is Fedora Chrome, right side is Adobe Reader with the wkhtml-generated PDF.

[benfavre]

This kerning issue has been going on for some time especially flagrant with smaller font sizes.
I fear it's more of a webkit bug, but i can confirm this has been going on since at least 0.9 since i started using wkhtmltopdf.
Phantomjs seems to have this issue also but only on very tiny font sizes.

[ashkulz]

I can see that this issue does occur, but until I get a clear idea on what is the root cause I'm afraid I won't be able to do anything much on this. It could be due to either one or more of the following:

• incorrect build options/environment
• runtime libraries/configuration
• distro/OS-specific
• issue in Webkit
• issue in QT

Can we collect information on what works, and what doesn't? @benfavre: you said that it works better on phantomjs -- can you post screenshots? phantomjs uses QPA for running headless, but it is implemented by patching QT in wkhtmltopdf.

[npinchot]

For what it's worth, this doesn't happen on OS X.

Here's a PDF rendered on OS X from the test.html document mentioned above.

However, as you might notice, the OS X binaries are currently producing PDFs that are rasterized (text is not selectable). More info available on this at phantomjs issue 10373.

[npinchot]

@ashkulz Sorry if I was confusing on the selectable text issue on OS X. This non-selectable text issue on OS X is still an issue (text is not selectable - not fixed). This has been persistent for as long as I know of.

[ashkulz]

@npinchot: can you see if #1501 generates selectable text? I suspect that the display is good in OS X due to the fonts being rasterized at a high DPI (and not rendered natively, as on other platforms).

[dandersson]

@ashkulz: The version of wkhtmltopdf I used in the first post of this issue was compiled on the machine it was run (Debian Sid i386), with the ./build_linux.sh linux-i386 helper. I checked recompiling with ./build_linux.sh linux-local, and that resulting binary generated a PDF that was binary identical to the one generated before (apart from embedded creation date), which perhaps was expected.

But: I just ran ./build_linux.sh linux-local with rev 60b024f on a remote Fedora (amd64) machine. The resulting binary there produced much better results kerning-wise. In my case, that is actually the production machine where I want it to work in the end, so that is great for me.

After this, I tried transferring the i386 binary compiled on the Debian i386 machine to the Fedora machine and generate the PDF there. The resulting PDF was identical (sans creation date...) with the one from the wkhtmltopdf binary compiled natively on the Fedora machine.

So, where I compile doesn't seem to matter, but where I run it do. When running wkhtmltopdf on an up-to-date Fedora installation, it gives good results. When running it on Debian Sid (and from what it seems like from the earlier bug reports: also its derivatives and perhaps more distributions), it does not.

I generated a new minimal HTML test file to emphasize the difference. These two PDFs are generated using the same binary but on different computers. Century Schoolbook L on Fedora seems to render absolutely perfectly. Nimbus Sans L rendering seems a tiny bit wonky even on Fedora in the screenshot, but it's not that bad if one investigates several zoom levels, in my eyes. The PDFs are linked below if anyone wants to test themselves.

Fedora on the left, Debian on the right

• test2-on-fedora-amd64.pdf
• test2-on-debian-i386.pdf
• HTML code for test2 (on Pastebin)
• strace from Fedora run
• strace from Debian run

In the old bug report on Google Code, I had the exact same problems on Fedora and Debian, both using the statically compiled download of wkhtmltopdf 0.10.0 rc2 i386 from the project page. I know I have tried 0.11.0 rc1 as well on the Debian machine without any difference, but I don't know if I also tested that version on Fedora.

Perhaps very relevant: I noted that bold+italic Century Schoolbook L rendered the same with both 0.10.0 rc2 and current 0.12.1 on Fedora, both with good results! From this I tried generating a new test suite on Fedora and Debian respectively, with these results:

Fedora on the left, Debian on the right

Debian text overlayed as green (75% opacity) on top of the Fedora rendering

Note how the rendering is identical on italic and bold+italic.

• test3-on-fedora-amd64.pdf
• test3-on-debian-i386.pdf
• HTML code for test3

So, yeah, there is something to be said here. Perhaps someone with more knowledge of the internals can get some information from this. The kerning data for normal text seems to get calculated from incorrect metrics on Debian, but not on Fedora (at least not as bad), though it works with italic and bold+italic.

[ashkulz]

@dandersson: that's a very long and detailed post! Offhand, the only reason could be differences in the freetype and/or fontconfig libraries -- those are linked dynamically and apparently the ones in Fedora perform much better than the ones in Debian/Ubuntu. It could be either due to patches, build configuration or runtime configuration -- to track it down is a very thankless task.

However, does using WOFF fonts on Debian give you better results? If that is the case (and hopefully if the display is same on both Debian and Fedora) maybe we can recommend using them for perfect display until we are able to nail down the reason for the difference.

[dandersson]

@ashkulz: I'll check how WOFF fonts are handled on my system later (it could take up to a couple of days before I have the chance to, though), unless someone else experience the same behavior on a Debian related distribution and has the time to investigate directly. One should also test the behavior of bold non-italic fonts; perhaps they are related to the underlying rendering library's confusion of metrics.

[npinchot]

@ashkulz I compiled a binary from the macos-selectable-text branch and the strange set printer name issue I mentioned in this comment is still present:

Nates-MacBook-Pro:wkhtmltopdf nate$ bin/wkhtmltopdf http://www.google.com test.pdf
Loading pages (1/6)
QMacPrintEngine::setPrinterName: Failed to set printer named '0'.0%
QMacPrintEngine::setPrinterName: Failed to set printer named '600'.
QPainter::begin(): Returned false
Error: Unable to write to destination                              
Exit with code 1, due to unknown error.

When I get some time I'm going to give phantomjs a try and see if the issue is fully resolved there. If it is, I'll see if I can track down the differences.

[ashkulz]

@npinchot: let us discuss in the PR directly, not in this thread.

@dandersson: it looks like a known issue in debian, acknowledged in their wiki. Can you see if the changes mentioned in the wiki or this thread help you out, in addition to trying out WOFF?