Today we received an inquiry about wkhtmltopdf’s poor rendering of HTML to PDF with Google’s Roboto font. Roboto is one of the most popular fonts and so it’s important for this to be resolved. The issue with this rendering problem is known as “kerning” which means that the spacing between the fonts is incorrect. Our support will do a best effort in research and guidance, though we cannot guarantee a solution if there is an issue with the underlying technology. And that’s what we faced here with wkhtmltopdf.

The customer did a comparison using our API endpoints between wkhtmltopdf and Headless Chrome. Our Headless Chrome endpoint did not have the same rendering issues as wkhtmltopdf. In general, we recommend always using Headless Chrome instead of wkhtmltopdf for your new projects as it is more modern. However, we still wanted to try and assist with the resolution here since wkhtmltopdf is nonetheless a popular library given its history.

In our research, we found this github issue that seems to have been ongoing for 4+ years: https://github.com/wkhtmltopdf/wkhtmltopdf/issues/45

A lot of the discussion has to do with the operating system and what not, and frankly much of it went over my head. However, there was one suggestion that stood out — and that was to set the DPI flag to 200. The default for wkhtmltopdf is 96, so we gave this a shot.

And it worked!

For API2PDF customers, all you need to do is specify in your advanced wkhtmltopdf options two flags:

• printMediaType: true
• dpi: 200

See how to use our advanced options and flags for wkhtmltopdf here.

Hope that helps.

Tags: bad kerning wkhtmltopdf, html to pdf custom fonts, html to pdf font issues, html to pdf roboto, render html as pdf, wkhtmltopdf custom fonts, wkhtmltopdf kerning