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?

[dandersson]

@ashkulz: Yes, with a font configuration file with these contents as per the Debian wiki entry, the result on Debian Sid is also good! I'd actually say it is even better than on Fedora, but the difference is not major, and certainly not related to wkhtmltopdf.

• test3-on-debian-i386-with-updated-font-configuration.pdf

As further information in case anyone is looking for the solution to the same problem: the Debian wiki says that the configuration file should be named ~/.fonts.conf, but that is actually deprecated, and such a file produces, when wkhtmltopdf is run:

Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. please move it to /home/daniel/.config/fontconfig/fonts.conf manually

…but not even this is really true, at least not on my machine, since ~/.config/fontconfig/fonts.conf says that it is "maintained by Font Manager", and the local configuration changes should really be placed in ~/.config/font-manager/local.conf which is then sourced through ~/.config/fontconfig/fonts.conf on access. I'll see if I can get the Debian wiki updated.

So, it seems that the problem with the "original" 2009 bug was underlying libraries that currently reside in different patched states across different distributions. Also, something must have changed in wkhtmltopdf in somewhat recent versions, since 0.10.0 rc2 still gives bad results on Fedora. According to the Debian wiki, the library changes have not yet propagated to the current Debian Stable release. Recent Fedora distributions seem fine. I don't know the status of e.g. Ubuntu 12.04 LTS.

WOFF on Debian Sid, with and without font configuration changes, gives the following results:

Updated font configuration on the left, vanilla on the right

Vanilla font configuration PDF overlayed on PDF with updated configuration

• test4-on-debian-i386-with-updated-font-configuration.pdf
• test4-on-debian-i386-with-vanilla-font-configuration.pdf
• HTML code for test4

In conclusion, the problems for which I opened this issue are resolved in the latest code revisions from what I can see. Perhaps there are some users who followed the old issue #72 on Google Code that are still having problems. In that case I guess they will have to bring additional information here, or open a completely new issue.

[ashkulz]

@dandersson: thanks for the confirmation! The underlying QT was upgraded to the latest 4.8 release (4.8.5) for 0.12.0, which would have fixed any issues at the QT end (if any).

I really appreciate your detailed (and screenshot-ful) comments -- I wish all bug reports were like that 👍

[ashkulz]

Also, @trvrnrth made a change for font kerning in wkhtmltopdf/qt@091befc -- that may well have done the trick -- it is even in the release notes for 0.12.0 :)

[xathien]

Pardon commenting on a closed thread, but I wanted to confirm that adding the contents posted by @dandersson to a file in /etc/fonts/conf.d/ also did the trick for my CentOS rendering issues; no need for base64-encoded fonts or every other workaround I was trying.

Thanks so much!

[ashkulz]

I'll try to see that this gets documented on the website; added a tag to track that.

[ashkulz]

Binaries for Linux/Windows (32/64-bit) of the latest development snapshot are available, please test whether they work for you (i.e. no regressions). Mac OS X binaries should be available in a day or so.

[npinchot]

Mac OS X binaries are available now as well.

[ghost]

Hi all, sorry for posting in a closed thread.

I'm one of those folks following the old #72 issue. I've just downloaded the latest development snapshot binaries (for Win32 and Win64, 0.12.1-773cad3.) and I've just checked that this issue still remains in such builds.

These are the outputs of wkhtmltopdf (the .pdf output as rendered by PDF-XChange Viewer) and Chrome (the source .xhtml file as rendered by Chrome).

This is a detail of the wkhtmltopdf resulting .pdf file, showing evident flaws.

I've compared this output to those obtained by 0.10 rc2 and 0.11 rc2 binaries and they look identical.

Perhaps this issue has not been solved yet on Windows boxes?

[ashkulz]

@emece67: try using --dpi 96 or --zoom 1.3, it gives better results for some people.

[ghost]

Thanks for the tip, the --zoom 1.3 option gives much more legible results. Unfortunately there still are some issues. Above the expected result, below the wkhtmltopdf rendering. Note the larger space between u-c and the smaller ones in e-d-í in the wkhtmltopdf rendering.

[AnderssonPeter]

Sadly this still seems to be a issue on windows tried both 0.12.1.0 and 0.12.3.2 both seem to have the same issue, but it's only visible with small font sizes.

test.html:

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <title>Test</title>
        <style>
        html {
          font-size: 10px;
        }
        body {
          font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
          font-size: 14px;
          line-height: 1.42857143;
          color: #333333;
          background-color: #fff;
        }
        .small
        {
            font-size: 0.8em;
        }
        </style>
    </head>
    <body>
        <h1>Test1</h1>
        <h2>Test2</h2>
        <h3>Test3</h3>
        Test4
        <div class="small">
            Namn small text name test ll11
        </div>
    </body>
</html>

Arguments: wkhtmltopdf.exe test.html test.pdf --encoding UTF8 --disable-smart-shrinking

Browser output:

wkhtmltopdf output:

I have tried with and without the --disable-smart-shrinking different result but same issue, look at the m and a in small they have merged!

[benfavre]

Generally speaking the output of Fonts is handled at the system level.
I have had success tweeking my Ubuntu box with "infinality"

add-apt-repository ppa:no1wantdthisname/ppa
apt-get update
apt-get install fontconfig-infinality
/etc/fonts/infinality/infctl.sh setstyle win7

[rstarkov]

I am not sure whether this is applicable to wkhtmltopdf, but I recently had a kerning issue in Windows when Word was invoked from a service via COM. This issue was resolved by selecting a printer, namely "Microsoft XPS Document Writer", instead of relying on the default one.

I've not seen the internals of wkhtmltopdf, but I do wonder if that could help here. Surely Webkit has some sort of a printer setting; perhaps it will have the desired effect? I was skeptical about this myself, thinking "what could that possibly have to do with save-to-PDF", but it does in Word, so maybe it also does in Webkit?

[chherren]

I have the same Problem like AndressonPeter.
I use wkhtmltopdf 0.12.3 on a Debian 7.9 Server.
I tried --disable-smart-shrinking and also diferent zoom-factors.
With the Font Arial it is verry bad. With the Font Verdana it looks a bit better.

Does everyone have an idea, how i can fix that problem?

Test.pdf

[AnderssonPeter]

@chherren try to avoid small font sizes as those seem to get the worst merging of chars but so far i haven't been able to eliminate the issue completely.

[punchi]

the solution that @nouknouk gives, worked for me too!! and I had to zoom 0.8 for CentOS (AWS Linux), working on Windows 7 @ashkulz any way to get a fix from the wkhtmltopdf side? at least a "FAQ" or like? I found the solution after many days with try/error and searching, as I'm working with a wrapper for Laravel too! (https://github.com/barryvdh/laravel-snappy) btw, thanks for the library! =)

[kylemacfarlane]

I was having this problem and followed the instructions of creating a 10-wkhtmltopdf.conf but that then caused #2505 to manifest and incorrectly wrap some lines. Both the kerning and the wrapping seem to be caused by the hinting settings.

I found the real solution was to upgrade freetype to 2.7 and all problems were fixed. I also have a box with freetype 2.4 installed that wasn't having problems but 2.7 has much better kerning so I'd advise going for the newest version you can.

[s5]

One thing that worked for me was using an SVG font instead of TTF or WOFF, at least for the Google Font Abril Fatface.

Notice the "o" and "e" when using TTF/WOFF:

And looks great with SVG:

[KKSzymanowski]

I don't know if this is still relevant, but I solved the kerning issue on Windows 10 by setting the DPI to at least 200.

[stijnster]

@nouknouk I wish I could cuddle you!

[alqu]

@nouknouk Amazing! I fixed the bad kerning with the config both on Debian Jessie and CentOS 7. Cool.

[saltire]

The Debian page seems to have changed, so here's the XML mentioned in @nouknouk's answer:

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
 <match target="font">
  <edit mode="assign" name="rgba">
   <const>rgb</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hinting">
   <bool>true</bool>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hintstyle">
   <const>hintslight</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="antialias">
   <bool>true</bool>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="lcdfilter">
   <const>lcddefault</const>
  </edit>
 </match>
</fontconfig>

It fixes the same issue with PDF rendering in PhantomJS, too. I was running an AWS Elastic Beanstalk machine, and used .ebextensions to add this file to the system.

[jishcat]

@KKSzymanowski Thank you for your comment:

I solved the kerning issue on Windows 10 by setting the DPI to at least 200.

It worked for me too. Definitely a problem, don't know why 96dpi is the default.

[SoTDarksoul]

Hi all, sorry for posting in a closed thread.

I tried everything that has been posted here but it seems my output doesn't match with my output version from Windows.

I'm on CentOS.

I created the file 05-wkhtmltopdf.conf but with or without it it doesn't change anything.
The file contains the text from @saltire .

Am I missing something?

UPDATE : changed the file to be a symbolic link, but it's still not working

[kmahalingpur]

@SoTDarksoul try to update 51-local.conf it will work

[vinhluan]

@s5 I'm having the same issue, but I can't seem to find the font in svg format. Could you tell me where do you get it please?

UPDATE: Nevermind, I got the ttf files from google font repo and converted them using an online tool.

[mcmz]

See: #2022
Rendering in opentype format .otf did the trick for us.

[xmoles]

Hello
Why happent this problem

](url)

[mayadafahim]

@vinhluan how did you use the SVG file exactly to make it work

[rbk]

Found a solution to fix the kerning issue when using WKHTMLToPDF on AWS Lambda (Serverless) https://www.internalpointers.com/post/fixing-ugly-fonts-chrome-chromium-debian-xfce.

1. set two environment variables:

provider:
  name: aws
  runtime: python3.6
  environment:
    FONTCONFIG_PATH: '/var/task/fonts'
    FONTCONFIG_FILE: '/var/task/fonts/fonts.conf'

2. Put this in your fonts.conf file in your project.

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <match target="font">
    <edit name="antialias" mode="assign"><bool>true</bool></edit>
  </match>
  <match target="font">
    <edit name="hintstyle" mode="assign"><const>hintnone</const></edit>
  </match>
  <match target="font">
   <edit mode="assign" name="hinting"><bool>false</bool></edit>
  </match>
</fontconfig>

[davehax]

I don't know if this is still relevant, but I solved the kerning issue on Windows 10 by setting the DPI to at least 200.

This works on Azure App Service (Basic Tier or higher) as well 👍