wkhtmltopdf documents producing differently in development vs production

49 views Asked by At

The following layout for producing PDFs is set to use a css file in the Rails' application assets/public directory, because the wicked-pdf gem requires static links. It is adjusted for each environment - localhost, a remote development and a remote production server (the latter two referencing the domain serving the application).

<!DOCTYPE html>
<html>
<head>
<title></title>
    <meta charset='utf-8' />
    <%= wicked_pdf_stylesheet_link_tag "http://localhost:3000/assets/zapp_pdf.css" %>
    <%= stylesheet_link_tag "http://netdna.bootstrapcdn.com/font-awesome/4.0.3/css/font-awesome-64.css", media: "all", "data-turbolinks-track" => true %>
    <%= stylesheet_link_tag "http://netdna.bootstrapcdn.com/font-awesome/4.0.3/css/font-awesome.css", media: "all", "data-turbolinks-track" => true %>
</head>
<body>
    <%= yield %>
</body>
</html>

Initially, the reference was called with wicked_pdf_stylesheet_link_tag Rails.application.assets.find_asset('zapp_pdf.css').digest_path but then fell back to an outright static non-fingerprinted css file

The result produced is different in ALL three cases (and was consistent with both syntassi for the css file)

• on remote development server text appears in proper spots but with no backgrounds

• while on remote production, style for backgrounds appear, but no text

• On localhost, all elements are present as expected (basically comining the two images!

It is very unclear why three different renderings could come about... unless other assets are being invoked in development mode selectively. What is going on? How to debug such a situation with wicked-pdf?

Update the experiment was extended to using to reference a static file on a separate server, lest some quirky cache effect be in place. The behaviour remains identical as above - i.e. the css interpretation is different between the three contexts.

.

1

There are 1 answers

0
Jerome On

Short answer:
wkhtmltopdf , being both archived and having issues with flexbox (as this application relies upon) must be discarded. it still amazes me that three different renderings are obtained with the same code

Alternatives are Prawn, DocRaptor, Ferrum and Grover.

Each has its hurdles or challenges.