I am using Rails pdfkit gem to render multi-page pdf files. The rendered pdf file picks up the CSS(SCSS) styling and page breaks as expected. However, when I try to render the same pdf document in production, it seems like the styling only loads some CSS rules and ignores others such as parent container's width
and height
declarations. Here is my CSS (SCSS) for the parent container element:
.policy_pdf{
font-family: Arial, sans-serif;
.pdf-page{
width:98%;
height:17.1in;
margin:auto;
page-break-after:always;
...
@media screen{
border: 1px dotted red;
}
page-break-after:always;
}
...
}
and PDFKit initializer:
PDFKit.configure do |config|
config.default_options = {
:page_size => 'Legal',
}
end
Here is an example of a pdf rendered in development:
and here is how this same pdf looks in production:
The red line around the doc is a CSS rule I introduced to display how page edges are rendered in production.
Both, development and production (Digital Ocean Droplet) are using the same version of Ubutnu (16.04).
At first I thought that some of the CSS classes I am using for pdf-kit
such as .page
get overwritten by some conflicting rules at compilation, so I tried using unique class names such as .pdf-page
instead of .page
.
I then tried to see whether it can be related to SCSS compilation. But nested border and background-color declarations within the same stylesheet are getting 'picked-up' and rendered fine. The policy-pdf
block inside the compiled application.css
looks correct as well.
Disabling smart-shrinking
made the PDF look even more "crumbled".
Applying size / width CSS rules (in-line and via external stylesheet) to the html
tag as suggested in this post:
Both, production and development are running the same version of wkhtmltopdf
of (~> 0.12.2
). However, running wkhtmltopdf -V
, returns wkhtmltopdf 0.12.2.1
(with patched qt)
I had similar porblem. In my case it was missing fonts on Ubuntu.
sudo apt-get install ttf-mscorefonts-installer
sudo fc-cache
https://askubuntu.com/questions/651441/how-to-install-arial-font-in-ubuntu
I had such problem a while back too. I'm not sure, but if I recall correctly, it ended up being different versions of ghost-script.
You can check the version by running gs -v
The production output appears to have larger margins than the dev output.
From your given sample of the relevant css showing your "page config", this might be simply fixed by specifying those margins. This isn't done on the virtual page element .pdf-page
, but inside the @page
selector.
@page {
margin:10mm 15mm 10mm 15mm;
}
Depending on how this design has being developed and previewed, (print dialog, dev tools media emulation) you may need to adjust those margins to conform to the margins used to preview the work. This can be done within the Chrome print dialog by setting Destination to 'Save as PDF', expanding 'More settings', selecting 'Customised' within Margins and finally entering the values or directly dragging the margins that now appear over the print preview.
While I'm not familiar with PDFKit, I've developed templates for AthenaPDF, I assume they're all pretty much standard PDF converters using Headless Chrome under the hood. We found it was easier and more flexible to define the @page properties through css rather than attempt to configure it through the AthenaPDF docker service. It only took standard, minimal and none as margin values.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With