Skip to content
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

bad kerning for fonts in output PDF #45

Closed
dandersson opened this issue Feb 6, 2014 · 76 comments
Closed

bad kerning for fonts in output PDF #45

dandersson opened this issue Feb 6, 2014 · 76 comments

Comments

@dandersson
Copy link

@dandersson dandersson commented Feb 6, 2014

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.

@ashkulz
Copy link
Member

@ashkulz ashkulz commented Feb 6, 2014

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
Copy link
Member

@ashkulz ashkulz commented Feb 6, 2014

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

@xathien
Copy link

@xathien xathien commented Feb 6, 2014

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.
image
Left side is Fedora Chrome, right side is Adobe Reader with the wkhtml-generated PDF.

@benfavre
Copy link

@benfavre benfavre commented Feb 6, 2014

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
Copy link
Member

@ashkulz ashkulz commented Feb 7, 2014

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.

@ashkulz ashkulz added the NeedInfo label Feb 7, 2014
@npinchot
Copy link
Contributor

@npinchot npinchot commented Feb 7, 2014

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
Copy link
Contributor

@npinchot npinchot commented Feb 7, 2014

@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
Copy link
Member

@ashkulz ashkulz commented Feb 7, 2014

@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
Copy link
Author

@dandersson dandersson commented Feb 7, 2014

@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
2014-02-07-145536_1680x1050_scrot

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
2014-02-07-154956_1680x1050_scrot

Debian text overlayed as green (75% opacity) on top of the Fedora rendering
2014-02-07-154956_1680x1050_scrot-overlay
Note how the rendering is identical on italic and bold+italic.

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
Copy link
Member

@ashkulz ashkulz commented Feb 7, 2014

@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
Copy link
Author

@dandersson dandersson commented Feb 7, 2014

@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
Copy link
Contributor

@npinchot npinchot commented Feb 7, 2014

@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
Copy link
Member

@ashkulz ashkulz commented Feb 8, 2014

@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
Copy link
Author

@dandersson dandersson commented Feb 8, 2014

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

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
2014-02-08-132248_1680x1050_scrot

Vanilla font configuration PDF overlayed on PDF with updated configuration
2014-02-08-132248_1680x1050_scrot-overlay

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 ashkulz removed the NeedInfo label Feb 8, 2014
@ashkulz
Copy link
Member

@ashkulz ashkulz commented Feb 8, 2014

@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 ashkulz closed this Feb 8, 2014
@ashkulz
Copy link
Member

@ashkulz ashkulz commented Feb 8, 2014

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
Copy link

@xathien xathien commented Feb 11, 2014

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 ashkulz added this to the 0.12.x milestone Feb 12, 2014
@ashkulz
Copy link
Member

@ashkulz ashkulz commented Feb 12, 2014

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

@ashkulz
Copy link
Member

@ashkulz ashkulz commented Feb 13, 2014

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
Copy link
Contributor

@npinchot npinchot commented Feb 13, 2014

Mac OS X binaries are available now as well.

@emece67
Copy link

@emece67 emece67 commented Feb 21, 2014

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

wk1

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

wk2

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
Copy link
Member

@ashkulz ashkulz commented Feb 22, 2014

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

@emece67
Copy link

@emece67 emece67 commented Feb 22, 2014

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.

image

dporru added a commit to wendbv/docker-wkhtmltopdf that referenced this issue Oct 5, 2016
dporru added a commit to wendbv/docker-wkhtmltopdf that referenced this issue Oct 5, 2016
@AnderssonPeter
Copy link

@AnderssonPeter AnderssonPeter commented Nov 3, 2016

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:
browser output
wkhtmltopdf output:
wkhtml 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
Copy link

@benfavre benfavre commented Nov 3, 2016

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
Copy link

@rstarkov rstarkov commented Nov 3, 2016

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
Copy link

@chherren chherren commented Jan 12, 2017

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
Copy link

@AnderssonPeter AnderssonPeter commented Jan 12, 2017

@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
Copy link

@punchi punchi commented Jan 18, 2017

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
Copy link

@kylemacfarlane kylemacfarlane commented Mar 13, 2017

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
Copy link

@s5 s5 commented Jun 9, 2017

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:
screenshot 2017-06-09 01 51 53

And looks great with SVG:
screenshot 2017-06-09 01 52 23

@KKSzymanowski
Copy link

@KKSzymanowski KKSzymanowski commented Jun 9, 2017

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
Copy link

@stijnster stijnster commented Jul 7, 2017

@nouknouk I wish I could cuddle you!

@alqu
Copy link

@alqu alqu commented Jul 31, 2017

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

@saltire
Copy link

@saltire saltire commented Aug 1, 2017

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
Copy link

@jishcat jishcat commented Aug 10, 2017

@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
Copy link

@SoTDarksoul SoTDarksoul commented Feb 1, 2018

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

Am I missing something?

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

@kmahalingpur
Copy link

@kmahalingpur kmahalingpur commented Aug 24, 2018

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

@vinhluan
Copy link

@vinhluan vinhluan commented Aug 27, 2018

@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
Copy link

@mcmz mcmz commented Oct 5, 2018

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

@xmoles
Copy link

@xmoles xmoles commented Nov 18, 2018

Hello
Why happent this problem
315ffe0d-f157-4c93-828d-9f46cb036938
](url)

@mayadafahim
Copy link

@mayadafahim mayadafahim commented Jun 6, 2019

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

@rbk
Copy link

@rbk rbk commented Jun 24, 2019

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'
  1. 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
Copy link

@davehax davehax commented Jul 17, 2019

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 👍

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

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.