incorrect font kerning on Windows produces bad output

[glenviewjeff]

Take the following page: http://www.myrecipes.com/recipe/chicken-braised-wine-rosemary-50400000126800/print/

It's especially apparent when zoomed out. It's as if there's no font smoothing or something.

Rendered with wkhtmltopdf:

Rendered with Acrobat:

Rendered with wkhtmltopdf:

Rendered with Acrobat:

[npinchot]

Which version is this and what platform is this on, etc?

This is what I get on OS X with the current development snapshot. The text rendering is by no means perfect, but perhaps it's better with the current development snapshot?

The OS X version is now using the native platform PDF renderer, so there may be some differences there.

Here's one rendered from the latest development snapshot on Ubuntu 12.04.4 LTS (displayed on OS X in Preview, the default PDF viewer - sorry I don't have anything else).

[glenviewjeff]

Sorry about that, I forgot to mention it's Windows 7, Cygwin if relevant.
I can't recall if this tool is dependent upon Ghostscript. If so, is that
where the problem lies?
On Feb 13, 2014 6:22 PM, "Nate Pinchot" notifications@github.com wrote:

Which version is this and what platform is this on, etc?

This is what I get on OS X with the current development snapshothttps://sourceforge.net/projects/wkhtmltopdf/files/0.12.1-773cad3/
.

The OS X version is now using the native platform PDF renderer, so there
may be some differences there.

[image: screen shot 2014-02-13 at 6 11 42 pm]https://f.cloud.github.com/assets/174529/2166814/c4a66864-950c-11e3-9435-4894f21a42f0.png

[image: screen shot 2014-02-13 at 6 13 39 pm]https://f.cloud.github.com/assets/174529/2166818/e24f34fe-950c-11e3-8c14-11f949fb8f63.png

Here's one rendered from the latest development snapshot on Ubuntu 12.04.4
LTS (displayed on OS X in Preview, the default PDF viewer - sorry I don't
have anything else).

[image: screen shot 2014-02-13 at 6 20 48 pm]https://f.cloud.github.com/assets/174529/2166864/dfc07648-950d-11e3-8b21-9991e8780e83.png

[image: screen shot 2014-02-13 at 6 21 12 pm]https://f.cloud.github.com/assets/174529/2166867/ede8978c-950d-11e3-8b28-2ddf9e8d9345.png

Reply to this email directly or view it on GitHubhttps://github.com//issues/1527#issuecomment-35043200
.

[npinchot]

Can you try the current development snapshot for Windows 32-bit or 64-bit to see if it's any better?

[glenviewjeff]

Your Mac versions all look far better than Windows, but the spacing in the development version snapshot you provided seemed to have fixed the serious spacing problem that the older Mac snapshots you showed. Did you notice the huge space between "mashed" and "potatoes"?

Development snapshot (64-bit version) seems to have fixed the anti-aliasing, but the kerning still looks awful on Windows.

Highlighting some of the more obvious problems:

[glenviewjeff]

Oh, and this (xkcd):

[npinchot]

Yep, kerning :)

I don't think this is something we can address quickly; we will need Qt changes for this. I ran this through phantomjs and there are similar kerning issues (as well as the mashed potatoes spacing issue):

[mn4367]

Below are two examples created on Windows 7 64. The first one is without using --zoom, the second was created with --zoom 1.3:

It's interesting to see that with zoom the result is better. I used --zoom 1.3 because on Windows a different scaling in Webkit (or whatever) seems to be used. If you put a

in the document with margin: 0; and width: 100mm; you have to use this zoom factor to get a

with a width of exactly 100mm. On OS X this isn't necessary (this is the same behavior as with older versions of wkhtmltopdf).

Edit:
Checked with more different fonts on Windows 7 64. Interestingly Times New Roman and Arial seem to produce very bad results. With other fonts (Palatino Linotype, Corbel, Cambria, Consolas, Constantia, Georgia) the results are much better.

[ashkulz]

Looks like QTBUG-11387 to me, should investigate whether the patch in #1620 improves the kerning.

[davewhitley]

I have had similar kerning issues on OS X (Chrome) with system fonts, in this case Georgia. Custom fonts seem to do the same thing.

generated pdf (Preview App):

generated pdf (Adobe Illustrator):

zoomed in web text (Chrome 35.0.1916.153):

You can see that the zoomed in web text is much nicer. The "o" letters have the worst kerning.

Let me know if my html/css/js would be helpful.

[mn4367]

generated pdf (Preview App):

This is the PDF generated by wkhtmltopdf or is it created by Chrome 35 on OS X?

generated pdf (Adobe Illustrator):

I suppose you mean the result shown, when you open the generated PDF in Illustrator?

Yes, HTML/CSS/JS is always helpful, thanks.

[ashkulz]

Can you verify if the output is better with 0.13-alpha available from the downloads page?

[glenviewjeff]

Definitely not better, just tested. Do you want images?

[ashkulz]

Yeah, but it looks like a Qt issue because 0.13 is built with Qt 5.4.0 (which is the latest release).

[glenviewjeff]

Actually I should retract my statement. I forgot this was about kerning,
and there doesn't look like a kerning problem here, only a poorly
anti-aliased bold font in wkhtmltopdf in this case. Interesting thing is
that there's some weird artifacting on the letter el in the word "like"
from the recipe summary, various words in the photo caption, and in the
word "APRIL" under the summary, all in the Acrobat Printer Driver version.
This artifacting does not disappear even when zooming in very close. So at
least Adobe's got some rendering issues too. The anti-aliasing seems poor
in the chrome save as pdf file as well.

Browser: http://i.imgur.com/FI1C0MC.png
wkhtmltopdf 0.13-alpha: http://i.imgur.com/qIjfxX7.png
Acrobat Printer Driver: http://i.imgur.com/anapsN9.png
Chrome's built-in "print as pdf": http://i.imgur.com/Avx9J5f.png

[glenviewjeff]

A couple of other things, I realized I didn't include the "mashed potatoes" text in the screenshot. It's kerned correctly in the 0.13-alpha rendering. I see no kerning issues, but subjectively the quality of the rendering is the worst out of the four.

[rstarkov]

The kerning in 0.13-alpha has certainly changed, but I wouldn't say it has improved. Previously the letters were mostly too close, with irregular spacing. Now they are too far, also with irregular spacing.

Comparison: http://i.imgur.com/ud3T5RA.png

I appreciate this is a Qt thing, thanks for trying to fix it but looks like Qt still can't do this right on Windows.

[MartyMcMartface]

I found a very nice workaround for this issue which might also shed some light on the problem (using wkhtmltopdf 0.12.2.1).

Firstly I saw in some other thread that SVG fonts don't have these kerning issues which is correct. The problem is that the resulting PDF is much larger and the text in it isn't selectable, so using SVG wasn't a viable workaround for me.

The trick is to convert the SVG font back to WOFF, which I did using Online Font Converter. This produces a WOFF that has perfect kerning just like the SVG. The only strange thing is the line height of the generated WOFF font is not the same as the original and can be many times higher than it should be, but this can be solved using line-height CSS (I just added line-height:1.25em everywhere I set the font-size). It might be possible to fix it by tinkering with the SVG instead but the CSS fix was good enough for me.

One font I used for testing was Century Gothic from dailywf.com. Using their WOFF or TTF directly has kerning issues, with the most notable issue being a huge gap after the letter w. However the WOFF font generated by converting the SVG font using the Online Font Converter has perfect kerning, but with a huge line-height. I also tried converting the Century Gothic TTF from the Windows fonts folder to SVG and then converting the result of that to WOFF and that also works well, with a more reasonable line-height but still slightly higher than normal. Note that converting the Windows TTF directly to WOFF doesn't fix the kerning, it has to go through SVG first.

The WOFF fonts generated by converting SVG fonts aren't good for the screen, so I include a fonts.css file on the wkhtmltopdf command line that contains @font-face declarations for all the affected fonts. These fonts can be named the same as local fonts and wkhtmltopdf will use the ones you supply, so you don't have to mess with your font names. Lastly, wkhtmltopdf doesn't like loading local URL assets from the command-line specified CSS file, so the @font-face declarations have to use data URLs.

Someone with more knowledge of the WOFF format might be able to compare the WOFF files generated by converting TTF and SVG and see why the former has kerning problems and the latter doesn't.

I hope this information helps someone!

[ashkulz]

@mart9634: can you post an example HTML/CSS/command-line with your workflow?

[MartyMcMartface]

@ashkulz: Some sample files are available here:
http://wildwildweb.com.au/temp/wkhtmltopdf-workaround-demo.zip
Not sure how I'm meant to create persistent attachments on this site so it's only on my temporary web server.

Here's the full workflow using the Windows Century Gothic font as an example:

1. Convert C:\Windows\Fonts\GOTHIC.TTF to SVG using Online Font Converter. This produces the file CenturyGothic.svg. Normally you'd also do the same for italic and bold variants.
2. Convert the CenturyGothic.svg file generated in step 1 to CenturyGothic.woff using the same Online Font Converter.
3. Convert the CenturyGothic.woff file to a data URL using an online tool such as DATAURL.NET. Note that most tools don't correctly identify the MIME type so need to replace application/octet-stream with application/font-woff in the output.
4. Create a CSS file called fonts-data.css that contains the @font-face definition of the font(s). Included in zip file.
5. Use the font-family:'Century Gothic' as normal in the CSS referenced from your HTML, but include line-height:1.25em every time you set the font-size. See test.html in the zip file.

To use the demo in the zip file:

1. Extract the zip to a folder
2. Copy wkhtmltopdf.exe (version 0.12.2.1) into the same folder
3. Modify the generate-pdf.bat file to specify the URL path to the folder
4. Run generate-pdf.bat. It should create two output files, one using the workaround and one without.

The letters in the PDF without the workaround are too big and all squished together.
Note that the output files I included in the attached zip is likely to render smaller than the output on other computers as I have Windows set to scale fonts at 150%.
Unfortunately wkhtmltopdf takes the Windows setting into account (making fonts smaller by the same factor) which makes it impossible to get consistent results across different machines, and causing production systems to break if an administrator comes along and changes the Windows font scaling setting.

I also included a file called wkhtmltopdf.css in the zip file. I normally include that file on the command line which includes the fonts-data.css file but I couldn't get it to work in this demo. Yet another wkhtmltopdf bug but not relevant to this issue.

[johannesspohr]

@mart9634 Thanks for the detailed post, i tried to follow your instructions for Arial and it really improved the output, but to me the kerning still seems wrong. Looking at "Gothic" in your demo, the "o" is too far on the left and the word "This" seems a lot denser than "Century" (compared it to a browser rendering which looks more balanced in my opinion).

It's a pity that the two most promising free html2pdf approaches (wkhtmltopdf and phantomjs) both can't solve this issue, which makes them effectively unusable for professional applications.

[MartyMcMartface]

@johannesspohr You're right I hadn't noticed is still isn't quite right. That problem seems to be only with small fonts. The font in my sample PDF is the equivalent of 6pt because my display is set to 150% scaling. There are a couple of ways you can improve kerning of smaller fonts:

• Remove the --disable-smart-shrinking option and use --zoom 1.25. I'm not actually sure what smart shrinking is but it seems to shrink everything by a factor of 1.25. When you correct that by zooming 1.25 the kerning in my example is better.
• If your professional application is back-end, set the windows scaling on the server to something very high like 200%. Then you can set --zoom 2.0 (or 2.5 if you combine it with the first option above) to get even more improvement.

If your professional application is front-end and you're concerned about precision kerning issues then wkhtmltopdf isn't of much use to you, simply because results depend on the Windows font scaling setting so you'll never be able to produce consistent results on all installations.

[johannesspohr]

@mart9634 Thanks, it's backend, and after deploying it to the production system (ubuntu 14) i noticed it works perfectly on it (my local installation runs on windows 7 x64). Weird problem though, i hope it will be fixed to work on any platform and zoom level.

[e-dot]

I had the same issue on Windows with latest wkhtmltopdf (0.12.4), and the only workaround was to increase the dpi to 200 or more (I picked 300).

Here's the **very very simple ** test case:
wkhtmltopdf.letter.spacing.issue.html (compressed)
wkhtmltopdf.letter.spacing.issue.zip

<html>
<head>
<title>HTMLPRINTTOPDF: Letter Spacing Issue (overwrite)</title>
</head>
<body>
<p>This is normal text</p>
<b><b>This is bold text</p>
</body>
</html>

Calling wkhtmltopdf with no options:
"C:\Program Files\wkhtmltopdf\bin\wkhtmltopdf.exe" wkhtmltopdf.letter.spacing.issue.html wkhtmltopdf.letter.spacing.issue.pdf

Here's the result:
wkhtmltopdf.letter.spacing.issue.pdf

Zooming on a word, you see the issue:

Calling the program with option --dpi 300 produces a good workaround:
"C:\Program Files\wkhtmltopdf\bin\wkhtmltopdf.exe" --dpi 300 wkhtmltopdf.letter.spacing.issue.html wkhtmltopdf.letter.spacing.issue.dpi.300.pdf

Here's the result:
wkhtmltopdf.letter.spacing.issue.dpi.300.pdf

Zooming on the same word, it's much better:

I'm fine using 300 dpi - we generate PDF for printing - but this font rendering issue is a pain.
Hope this could help,

Regards,

E.

[PhilterPaper]

I'm not sure I would call this a "kerning" issue... it looks to me more like poor character width management. Note in the previous post that they appear to be using the same typeface, but something's wrong with where the next glyph starts, even on letters where you would normally expect no kerning adjustments (such as "m" followed by "a"). Could WebKit be using different font width tables than the PDF reader is (same typeface, but different widths)? Is it possible to embed the font in the PDF, and see if that changes anything?

[pierluca]

Due to the behaviour of wkhtmltopdf with dynamically created SVGs with foreignObjects containing HTML, I'm working on a project where we can't increase the DPI without messing up the page entirely, as not all elements are scaled in the same way.

Furthermore, the project runs in the cloud and the GDI APIs aren't available, which restricts us from using custom fonts. As such, we're stuck with a kerning issue and a horrible letter-spacing workaround.

Is there any plan to fix this issue in the coming months ? Any pointer as to how to fix it ? We could invest some time, but we don't really know where to start. It's a bit of a deal breaker for us.

[MartyMcMartface]

@pierluca I ended up switching to a different library https://github.com/danfickle/openhtmltopdf which doesn't have any of these issues.

[pierluca]

@MartyMcMartface That won't cut it for us as we're rendering an AngularJS application which dynamically generates the SVG content :-/

[pierluca]

I might have just found out some important complementary information to what @MartyMcMartface mentioned, which is the solution we went with.

We were in the situation where Windows fonts were working more or less correctly but not free fonts. This wasn't acceptable.

I compared the svg generated from Windows TTF fonts and another SVG font (Liberation Sans) - converted to WOFF and then DataURL - that resulted in the wrong kerning.

Here's how I changed Liberation Sans for it to work (some changes may not be needed for it to work, I just went the full way):

• added "glyph-name" attribute to all glyphs
• use hkern g1 and g2 attributes (corresponding to glyph-name) rather than u1 and u2
• glyph with no corresponding unicode were removed from the SVG
• provided full font-face description (all attributes)

It's not perfect but this actually works !

[xmoles]

Sorry but i have the same problem
Why happent this problem
farhi_23-10-2018_18-02-35.pdf