use custom fonts with wkhtmltopdf

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.

Since it is a Google Web font you need not to write @font-face in you style sheet just use following link tag in your source code:

<link href='http://fonts.googleapis.com/css?family=Jolly+Lodger' rel='stylesheet' type='text/css'>

and

 <style type = "text/css">
    p { font-family: 'Jolly Lodger', cursive; }
</style>

will work.

By the way, in your code you are defining @font-face family as font-family: Jolly; and using it as p { font-family: 'Jolly Lodger', cursive; } that is wrong, because it's mismatching font-family name.

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.

If you have .ttf file or .woff file then use following syntax

@font-face {
   font-family: 'Sample Name';
   src: url(/PathToFolderWhereContained/fontName.ttf) format('truetype');
   }

don't use ttf that will not work rather use full name 'truetype' and if you have .woff then use 'woff' in format. For my case it worked.

However the best practice is to use links to Google fonts API that is best if not getting that matching your criteria then use this above technique it will work