All you can do is use a single font containing every unicode character.

If you have mixed scripts in your output (say, addresses in Japanese, but invoice items in English), you’re out of luck. While wkhtmltopdf loads web fonts fine (problems from point 4 notwithstanding), its handling of multiple font files listed under the same font family is atrocious. Actually please don’t – they are very nice if slightly weird people. Show its output to someone with a knack for typography and watch them cringe in terror. Some users report that increasing the output DPI helps, but the core issue is still not fixed. The GitHub repository has a bug open for four years now, showing atrocious kerning issues in rendered text. Or represent them very inefficiently as base64-encoded inline resources, which is especially bad if you are embedding large font files. Thus fetching them over the network (localhost, hopefully) instead of the filesystem. But hey, you can always expose your resources as absolute URLs pointing at some (hopefully internal) server. On Linux, absolute paths seem to work fine, but that is barely an acceptable solution. You have to browse GitHub Issues for an answer. Poorly documented (and generally poor) local resource accessĪre you supposed to use file:// URLs for local content? Or just paths? Does the tag work for setting where these assets can be found? No answers from the official docs. The CSS Paged Media spec has declarative syntax for all of that – but wkhtmltopdf does not support any usable subset of it. And no, rotating page content 90 degrees is not the answer, output may look usable on paper, but not in a viewer application. Want landscape pages? Sure, you can have them but all pages in your output will be landscape. One page size, one page layout per document If your documents are to be bound, and you need odd and even pages to format slightly differently – again, good luck. As the footer is global, the only thing you can do is run some JavaScript detecting footnote references in the page and stuffing their expansions into this page’s footer. What it doesn’t tell you is that it wants them to be complete, separate HTML documents, so you need to take extra steps to ensure they look like the rest of your document.Īlso, good luck with coherent footnotes – you’re fully on your own there. (Or use dumb plain-text content instead.) Then you get them on every page, no exceptions (and for page numbers… wait till the № 1 item on this list). One footer, one header, no footnotesĪll that the documentation tells you about headers and footers is that you can put them in separate HTML files and set them with options. If you’re running on cheap instances with low RAM wkhtmltopdf may be the death of your machine. But once launched, you cannot tell or control how much resources (memory in particular) it consumes – it’s a black box. All modern operating systems deal with this nicely, keeping it in cache so that frequent usage does not incur load time penalties. But still: unless you use something really slow, it may be faster to include a native PDF-generating library in your project and use that, instead of spawning a wkhtmltopdf process for each document you need to output. This is not a big issue nowadays, therefore it ranks lower in the list. The official GitHub repository does release official packages and binaries for the newest stable version – but the prerelease (0.13 at the moment), which may or may not fix issues further on in the list, is nowhere to be found – and back to the build issues we go. This makes getting at the newest version hard. One Docker Hub repo author stated problems with compiling it under two hours – which is Docker’s timeout for automated builds. Difficult to buildĬompilation requires Qt (currently an obsolete version) and WebKit, both hefty codebases. There are eight reasons why wkhtmltopdf shouldn’t be used for anything serious: 8.

Pdfkit vs princexml