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 · 69 comments

Comments

Projects
None yet
@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

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Feb 6, 2014

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Feb 6, 2014

Member

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

Member

ashkulz commented Feb 6, 2014

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

@xathien

This comment has been minimized.

Show comment
Hide comment
@xathien

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

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

This comment has been minimized.

Show comment
Hide comment
@benfavre

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

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

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Feb 7, 2014

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@npinchot

npinchot Feb 7, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@npinchot

npinchot Feb 7, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Feb 7, 2014

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@dandersson

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

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

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Feb 7, 2014

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@dandersson

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

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

This comment has been minimized.

Show comment
Hide comment
@npinchot

npinchot Feb 7, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Feb 8, 2014

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@dandersson

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

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

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Feb 8, 2014

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Feb 8, 2014

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@xathien

xathien 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!

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

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Feb 12, 2014

Member

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

Member

ashkulz commented Feb 12, 2014

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

@ashkulz

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Feb 13, 2014

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@npinchot

npinchot Feb 13, 2014

Contributor

Mac OS X binaries are available now as well.

Contributor

npinchot commented Feb 13, 2014

Mac OS X binaries are available now as well.

@emece67

This comment has been minimized.

Show comment
Hide comment
@emece67

emece67 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?

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

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Feb 22, 2014

Member

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

Member

ashkulz commented Feb 22, 2014

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

@emece67

This comment has been minimized.

Show comment
Hide comment
@emece67

emece67 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

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

@ashkulz

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Feb 22, 2014

Member

@emece67: I can see that there are differences, but I don't think it can be as perfect as that -- Chrome is using a much later version of Webkit/Blink.

Member

ashkulz commented Feb 22, 2014

@emece67: I can see that there are differences, but I don't think it can be as perfect as that -- Chrome is using a much later version of Webkit/Blink.

@dan-mesa

This comment has been minimized.

Show comment
Hide comment
@dan-mesa

dan-mesa Mar 5, 2014

@ashkulz, @xathien, regarding the following comment:

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.

On my CentOS install (v5.5) I have /etc/fonts/fonts.conf as well as the /etc/fonts/conf.d/ directory. Should I be placing an additional fonts.conf with the above suggested XML in /etc/fonts/conf.d/fonts.conf? I assume I'll need a server reboot to test the changes? Really hoping this fixes the kerning for me!

Also sorry for pinging a closed thread, but I figure this'll be helpful for documentation purposes.

dan-mesa commented Mar 5, 2014

@ashkulz, @xathien, regarding the following comment:

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.

On my CentOS install (v5.5) I have /etc/fonts/fonts.conf as well as the /etc/fonts/conf.d/ directory. Should I be placing an additional fonts.conf with the above suggested XML in /etc/fonts/conf.d/fonts.conf? I assume I'll need a server reboot to test the changes? Really hoping this fixes the kerning for me!

Also sorry for pinging a closed thread, but I figure this'll be helpful for documentation purposes.

@xathien

This comment has been minimized.

Show comment
Hide comment
@xathien

xathien Mar 5, 2014

@dan-mesa - If you look in /etc/fonts/conf.d/ you'll see a pile of files that have a two-number prefix to some file description. For me, there was also a README in that dir explaining the conventions of the filenames. Since I'm not a conventional guy, I just made "10-wkhtmltopdf.conf" to make sure it got read first and filled it with the file contents above.
No server reboot is necessary, as FontConfig will pick up the changes after a short time (don't know the exact window, but I've seen it quoted as "a few seconds" to "a few minutes").

xathien commented Mar 5, 2014

@dan-mesa - If you look in /etc/fonts/conf.d/ you'll see a pile of files that have a two-number prefix to some file description. For me, there was also a README in that dir explaining the conventions of the filenames. Since I'm not a conventional guy, I just made "10-wkhtmltopdf.conf" to make sure it got read first and filled it with the file contents above.
No server reboot is necessary, as FontConfig will pick up the changes after a short time (don't know the exact window, but I've seen it quoted as "a few seconds" to "a few minutes").

@dan-mesa

This comment has been minimized.

Show comment
Hide comment
@dan-mesa

dan-mesa Mar 5, 2014

Thanks for the quick reply, @xathien! Giving it a try now.

So I can hopefully contribute something, I did happen upon the rescan duration in fonts.conf but didn't realize what it was. Mine is set to 30 seconds:

<!--
  Rescan configuration every 30 seconds when FcFontSetList is called
 -->
    <rescan>
        <int>30</int>
    </rescan>

I see that directory included in there too - it's all starting to make a bit more sense ;)

dan-mesa commented Mar 5, 2014

Thanks for the quick reply, @xathien! Giving it a try now.

So I can hopefully contribute something, I did happen upon the rescan duration in fonts.conf but didn't realize what it was. Mine is set to 30 seconds:

<!--
  Rescan configuration every 30 seconds when FcFontSetList is called
 -->
    <rescan>
        <int>30</int>
    </rescan>

I see that directory included in there too - it's all starting to make a bit more sense ;)

@dan-mesa

This comment has been minimized.

Show comment
Hide comment
@dan-mesa

dan-mesa Mar 5, 2014

@xathien - fixed! Thank you again! @dandersson, thank you too, for your diligent testing.

So, for the world, confirming that the solution outlined above works on CentOS 5.5.

dan-mesa commented Mar 5, 2014

@xathien - fixed! Thank you again! @dandersson, thank you too, for your diligent testing.

So, for the world, confirming that the solution outlined above works on CentOS 5.5.

@zoplonix

This comment has been minimized.

Show comment
Hide comment
@zoplonix

zoplonix Apr 10, 2014

We have been using this for a project and have been trying to work around this issue endlessly.

You can see the root cause of the problem by opening the PDF in a vector drawing application like Adobe Illustrator.

wkhtmltopdf draws every single letter independently of itself. It looks like it creates a box for each letter and then manually specifies the location to put the letter on the page, based on the kerning settings of the font.

Other HTML to PDF generators don't do this. They create a box for a paragraph of text and specify where to put that box. Then the PDF "renderer" handles placing the letters in the box with the proper kerning at runtime when the PDF is opened to be read.

So it seems like the core issue is that wkhtmltopdf is calculating, and explicitly specifying, the kerning values for each and every letter when it shouldn't.

zoplonix commented Apr 10, 2014

We have been using this for a project and have been trying to work around this issue endlessly.

You can see the root cause of the problem by opening the PDF in a vector drawing application like Adobe Illustrator.

wkhtmltopdf draws every single letter independently of itself. It looks like it creates a box for each letter and then manually specifies the location to put the letter on the page, based on the kerning settings of the font.

Other HTML to PDF generators don't do this. They create a box for a paragraph of text and specify where to put that box. Then the PDF "renderer" handles placing the letters in the box with the proper kerning at runtime when the PDF is opened to be read.

So it seems like the core issue is that wkhtmltopdf is calculating, and explicitly specifying, the kerning values for each and every letter when it shouldn't.

@ashkulz

This comment has been minimized.

Show comment
Hide comment
@ashkulz

ashkulz Apr 11, 2014

Member

That's not done by wkhtmltopdf, that is the way the QT PDF rendering engine works (the same algorithm is used for displaying on screen and for PDF output).

Member

ashkulz commented Apr 11, 2014

That's not done by wkhtmltopdf, that is the way the QT PDF rendering engine works (the same algorithm is used for displaying on screen and for PDF output).

@maciejpuchala

This comment has been minimized.

Show comment
Hide comment
@maciejpuchala

maciejpuchala Aug 26, 2014

@xathien and @dan-mesa can you write, what to exactly do to repair that kerning (e.g. on Debian). You wrote about "suggested XML" and copy fonts.conf file, to other dir, but I can't read here what I have to exactly do.

@zoplonix do you have others/better html to pdf generator? I have used, a lot of it and wkhtml is the best choice for me right now (has best rendering).

maciejpuchala commented Aug 26, 2014

@xathien and @dan-mesa can you write, what to exactly do to repair that kerning (e.g. on Debian). You wrote about "suggested XML" and copy fonts.conf file, to other dir, but I can't read here what I have to exactly do.

@zoplonix do you have others/better html to pdf generator? I have used, a lot of it and wkhtml is the best choice for me right now (has best rendering).

@xathien

This comment has been minimized.

Show comment
Hide comment
@xathien

xathien Aug 26, 2014

For @maciejpuchala and others who are lazy and/or English-impaired:
sudo wget http://pastebin.com/raw.php?i=AmfYN3er -O /etc/fonts/conf.d/10-wkhtmltopdf.conf

I'll unsubscribe from further replies to this thread, now...

xathien commented Aug 26, 2014

For @maciejpuchala and others who are lazy and/or English-impaired:
sudo wget http://pastebin.com/raw.php?i=AmfYN3er -O /etc/fonts/conf.d/10-wkhtmltopdf.conf

I'll unsubscribe from further replies to this thread, now...

@spung

This comment has been minimized.

Show comment
Hide comment
@spung

spung Oct 19, 2015

@KateWilkins wow thanks, that actually solved my kerning issues on OSX as well. So far I can't discern any difference in quality with/without that flag.

spung commented Oct 19, 2015

@KateWilkins wow thanks, that actually solved my kerning issues on OSX as well. So far I can't discern any difference in quality with/without that flag.

@andylemay

This comment has been minimized.

Show comment
Hide comment
@andylemay

andylemay Nov 3, 2015

Hi nouknouk, jswing-mie,

Please excuse my ignorance. I tried as you said to create XML file and link it but it doesn't make any difference to wkhtmltopdf output.

Ubuntu 14.04.1, odoo 8

andylemay commented Nov 3, 2015

Hi nouknouk, jswing-mie,

Please excuse my ignorance. I tried as you said to create XML file and link it but it doesn't make any difference to wkhtmltopdf output.

Ubuntu 14.04.1, odoo 8

@jswing-mie

This comment has been minimized.

Show comment
Hide comment
@jswing-mie

jswing-mie Nov 3, 2015

@andylemay

It's possibly a difference in the distro so that link to Debian's wiki may not be useful to you. It worked for me on CentOS. Unfortunately, my knowledge on this subject ends with that wiki page so I have nothing left to offer. Sorry.

jswing-mie commented Nov 3, 2015

@andylemay

It's possibly a difference in the distro so that link to Debian's wiki may not be useful to you. It worked for me on CentOS. Unfortunately, my knowledge on this subject ends with that wiki page so I have nothing left to offer. Sorry.

@andylemay

This comment has been minimized.

Show comment
Hide comment
@andylemay

andylemay Dec 1, 2015

Here's the fix to the font smoothing / blocky fonts issue I was experiencing with Odoo 8.0 on Ubuntu 14.4.
This server was a bitnami build Odoo 8.0-12 (Odoo Version 8.0-20150423)

sudo apt-get remove xfonts-75dpi
sudo apt-get install xfonts-scalable

Beltran from Bitnami found this fix. How long have I been trying to fix this!

andylemay commented Dec 1, 2015

Here's the fix to the font smoothing / blocky fonts issue I was experiencing with Odoo 8.0 on Ubuntu 14.4.
This server was a bitnami build Odoo 8.0-12 (Odoo Version 8.0-20150423)

sudo apt-get remove xfonts-75dpi
sudo apt-get install xfonts-scalable

Beltran from Bitnami found this fix. How long have I been trying to fix this!

@joelostblom

This comment has been minimized.

Show comment
Hide comment
@joelostblom

joelostblom Jan 2, 2016

On Arch Linux, the wkhtmltopdf-static (0.12.2.1-1) package from the AUR is compiled against the patched Qt-libraries and worked for me without any modifications (although note that I have the Ubuntu patched version of cairo, freetype and fontconfig since previously).

The wkhtmltopdf (0.12.2.1-2) package from the ABS is compiled against the unpatched Qt-libraries and none of the earlier suggested modifications (--zoom 1.3, lowquality, adding xml config files) alleviated the issues of disproportionate character spacing.

joelostblom commented Jan 2, 2016

On Arch Linux, the wkhtmltopdf-static (0.12.2.1-1) package from the AUR is compiled against the patched Qt-libraries and worked for me without any modifications (although note that I have the Ubuntu patched version of cairo, freetype and fontconfig since previously).

The wkhtmltopdf (0.12.2.1-2) package from the ABS is compiled against the unpatched Qt-libraries and none of the earlier suggested modifications (--zoom 1.3, lowquality, adding xml config files) alleviated the issues of disproportionate character spacing.

@erikverheij

This comment has been minimized.

Show comment
Hide comment
@erikverheij

erikverheij Feb 1, 2016

Adding the XML config file as suggested by @nouknouk solved it for me!

I'm on a AWS Linux AMI (based on CentOS/RHEL).

erikverheij commented Feb 1, 2016

Adding the XML config file as suggested by @nouknouk solved it for me!

I'm on a AWS Linux AMI (based on CentOS/RHEL).

@MJBGO

This comment has been minimized.

Show comment
Hide comment
@MJBGO

MJBGO Feb 20, 2016

Perfect @nouknouk, works great ! Thanks 👍

MJBGO commented Feb 20, 2016

Perfect @nouknouk, works great ! Thanks 👍

dan-palmer added a commit to ministryofjustice/moving-people-safely-beta that referenced this issue Mar 3, 2016

dan-palmer added a commit to ministryofjustice/moving-people-safely-beta that referenced this issue Mar 3, 2016

Fix font kerning in container
There is a known *issue in Debian distros around subpixel 
hinting & font smoothing. Link below provides a description
& an example font configuration for fixing it.

This was highlighted in **below the wkhtmltopdf issue.

The font configuration(according to the Readme found in
`fonts/config.d/`) relies on ordering hence the `10-` prefix.


*  https://wiki.debian.org/Fonts#Subpixel-hinting_and_Font-smoothing

** wkhtmltopdf/wkhtmltopdf#45

dan-palmer added a commit to ministryofjustice/moving-people-safely-beta that referenced this issue Mar 3, 2016

Fix font kerning in container
There is a known *issue in Debian distros around subpixel 
hinting & font smoothing. Link below provides a description
& an example font configuration for fixing it.

This was highlighted in the **below wkhtmltopdf issue.

The font configuration(according to the Readme found in
`fonts/config.d/`) relies on ordering hence the `10-` prefix.


*  https://wiki.debian.org/Fonts#Subpixel-hinting_and_Font-smoothing

** wkhtmltopdf/wkhtmltopdf#45

dan-palmer added a commit to ministryofjustice/moving-people-safely-beta that referenced this issue Mar 3, 2016

Fix font kerning in container
There is a known *issue in Debian distros around subpixel 
hinting & font smoothing. Link below provides a description
& an example font configuration for fixing it.

This was highlighted in the **below wkhtmltopdf issue.

The font configuration(according to the Readme found in
`fonts/config.d/`) relies on ordering hence the `10-` prefix.


*  https://wiki.debian.org/Fonts#Subpixel-hinting_and_Font-smoothing

** wkhtmltopdf/wkhtmltopdf#45
@juukie

This comment has been minimized.

Show comment
Hide comment
@juukie

juukie Mar 20, 2016

Thanks @nouknouk. Adding the XML did the trick for me. (on CentOS)

juukie commented Mar 20, 2016

Thanks @nouknouk. Adding the XML did the trick for me. (on CentOS)

@jdavidbakr

This comment has been minimized.

Show comment
Hide comment
@jdavidbakr

jdavidbakr Mar 23, 2016

Just to chime in, I had a similar issue with the fonts rendering with wacky kerning and if copied and pasted from the generated PDF it would add spaces in random places. In my case it was only happening on my production server but not on my development server (both EC2 instances running identical Amazon AMI distros). I ran "sudo yum list installed | grep font" as a stab in the dark to see if there was something missing on the production machine that was not on the development machine, and two items showed up - ghostscript-fonts and urw-fonts. I installed both of these on my production machine and now both PDFs render correctly.

jdavidbakr commented Mar 23, 2016

Just to chime in, I had a similar issue with the fonts rendering with wacky kerning and if copied and pasted from the generated PDF it would add spaces in random places. In my case it was only happening on my production server but not on my development server (both EC2 instances running identical Amazon AMI distros). I ran "sudo yum list installed | grep font" as a stab in the dark to see if there was something missing on the production machine that was not on the development machine, and two items showed up - ghostscript-fonts and urw-fonts. I installed both of these on my production machine and now both PDFs render correctly.

@sjadema

This comment has been minimized.

Show comment
Hide comment
@sjadema

sjadema Apr 13, 2016

@nouknouk Thank you so much. Was having issues with font kerning in PhantomJS and this simple yet elegant solution fixed everything!

sjadema commented Apr 13, 2016

@nouknouk Thank you so much. Was having issues with font kerning in PhantomJS and this simple yet elegant solution fixed everything!

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

This comment has been minimized.

Show comment
Hide comment
@AnderssonPeter

AnderssonPeter 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!

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

This comment has been minimized.

Show comment
Hide comment
@benfavre

benfavre 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

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

This comment has been minimized.

Show comment
Hide comment
@rstarkov

rstarkov 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?

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

This comment has been minimized.

Show comment
Hide comment
@chherren

chherren 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

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

This comment has been minimized.

Show comment
Hide comment
@AnderssonPeter

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

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

This comment has been minimized.

Show comment
Hide comment
@punchi

punchi 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! =)

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

This comment has been minimized.

Show comment
Hide comment
@kylemacfarlane

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

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

This comment has been minimized.

Show comment
Hide comment
@s5

s5 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

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

This comment has been minimized.

Show comment
Hide comment
@KKSzymanowski

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

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

This comment has been minimized.

Show comment
Hide comment
@stijnster

stijnster Jul 7, 2017

@nouknouk I wish I could cuddle you!

stijnster commented Jul 7, 2017

@nouknouk I wish I could cuddle you!

@alqu

This comment has been minimized.

Show comment
Hide comment
@alqu

alqu Jul 31, 2017

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

alqu commented Jul 31, 2017

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

@saltire

This comment has been minimized.

Show comment
Hide comment
@saltire

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

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

This comment has been minimized.

Show comment
Hide comment
@jishcat

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

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

This comment has been minimized.

Show comment
Hide comment
@SoTDarksoul

SoTDarksoul 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

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

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