Rendered PDF looks different in production - Rails, PDFKit, wkhtmltopdf
Asked Answered
B

3

13

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: enter image description here

and here is how this same pdf looks in production: enter image description here

The red line around the doc is a CSS rule I introduced to display how page edges are rendered in production.

Environments

Both, development and production (Digital Ocean Droplet) are using the same version of Ubutnu (16.04).

What have you tried?

  • 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:

Clue:

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)

Beaujolais answered 31/3, 2017 at 23:29 Comment(1)
For me switching to the new server make documents diferent looks. It looks like i miss some font, but i am not sure. I am digging into itProlific
P
2

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

Prolific answered 11/5, 2019 at 21:31 Comment(0)
M
1

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

Marketplace answered 1/11, 2017 at 21:43 Comment(0)
T
1

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.

Tolliver answered 27/3, 2018 at 1:3 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.