use custom fonts with wkhtmltopdf

Question

I am trying to use custom fonts in my PDF generated with wkhtmltopdf. I read that you can\'t use google webfonts and that wkhtmltopdf uses truetype .ttf file. Can anyone con

Answer 1

As stated above by Yardboy we've found that base64 encoding the truetype font in our CSS works well. But I wanted to share some additional insight.

We use 4 custom fonts all uniquely named 'Light' 'Medium' etc..

I use openssl toolkit to base64 encode with good results. But you could alternatively use fontsquirrel. Just be sure to strip out all other font types ('woff' 'otf' .. ). We found that using truetype exclusively worked mysteriously.

Encode file, trim output and add to clipboard

openssl base64 -in bold.ttf | tr -d '\n' | pbcopy

In Windows you should install openssl and add it to path then

openssl base64 -in bold.ttf | tr -d '\n' | clip

or simply use this kind of websites

Add to css font src property

   @font-face {
      font-family: 'Bold';
      font-style: normal;
      font-weight: normal;
      src: url(data:font/truetype;charset=utf-8;base64,BASE64...) format("truetype");
    }

Rendered output will depend on your wkhtmltopdf version and flavor. Because our servers run Debian and I develop on OSX I tested on a VM locally.

Answer 2

I am betting you are calling wkhtmltopdf from a web wrapper using IIS. That's why some folks are saying that it does work for them. They are probably calling wkhtmltopdf from the command line, in which case it can resolve relative links in CSS URL()s but if you are calling it from snappy or the like you can get around the problem by specifying a URL like say URL('http://localhost/myfolder/fonts/JollyLodger-Regular.ttf') instead.

The inability to properly resolve relative links in CSS URL() tags appears to be broken in wkhtmltopdf 0.11.0_rc1 but some earlier versions might work okay. The same problem happens with other CSS URL() tags like when calling a background images - resolving the file location is broken. Interestingly though, in the case of images, if you use <IMG SRC=>, 0.11.0_rc1 is able to find the file, even if a relative path is provided. The problem appears to be limited to URL() tags inside CSS.

EDIT: I found out that if you use file:/// with all forward slashes in the path then it works. In other words URL('file:///D:/InetPub/wwwroot/myfolder/fonts/JollyLodger-Regular.ttf') should work.

Answer 3

I'll just add my answer here too, in case someone might need it.

I've been using Rotativa which builds upon wkhtmltopdf, and what I ended up using was the following:

@font-face {
    font-family: "testfont";
    src: url("/UI/Fonts/609beecf-8d23-4a8c-bbf5-d22ee8db2fc9.woff") format("woff"),
         url("/UI/Fonts/1cd9ef2f-b358-4d39-8628-6481d9e1c8ce.svg#1cd9ef2f-b358-4d39-8628-6481d9e1c8ce") format("svg");
}

...and it seem's Rotativa is picking up the SVG-version. If I reorder them it still works, but if I remove the SVG-version, it stops working.

Might be worth a shot. Can't find any good documentation on why this is so, however