DEV Community: Jerry Weyer

Converting PDFs to/from images in a Ruby on Rails application

Jerry Weyer — Fri, 05 Nov 2021 12:06:37 +0000

There are quite a few options if you need to convert images to/from PDFs in Ruby (on Rails). I am going to detail two of the most common options I came across in my projects: using ImageMagick and using an external API (ConvertAPI in my case).

ImageMagick

ImageMagick is a free open-source command line tool which enables you to convert images to/from PDFs (among other things). You can install the software directly on your system, or in a Rails app via the RMagick gem to create an interface between the Ruby programming language and the ImageMagick image processing library.

Once installed, you can manipulate images with the command-line interface (e.g. converting an image to a PDF of a certain size and DPI):

`convert -density 300 -units 'PixelsPerInch' image.jpg -extent 2479x3508 -format pdf result.pdf`

If you are using Rails Active Storage, ImageMagick is the default processor for image analysis and transformations. This allows you to create different image variants on upload, without the need to add your custom CLI commands:

<%= image_tag user.avatar.variant(resize_to_limit: [100, 100]) %>

ImageMagick is an extremely powerful tool, but getting it to do exactly what you want can be challenging at times. Check out the authoritative website imagemagick.org for all the different options at your disposal.

A disadvantage of ImageMagick is that managing installations and policies can be difficult if you do not have full access to your system. One problem I ran into when deploying to Heroku was that I could not directly read an image served via https, because of the restrictive default policy. The Heroku helpdesk article 'How can I override ImageMagick settings in a policy.xml file?' didn't solve the problem. I finally got the confirmation from Heroku support, that

[...] because we use the pre-packaged Ubuntu ImageMagic which is built with the 'installed' option you cannot override the policy from the system path [...] You can disable/reduce options that are enabled by the system policy but once something is disabled you can't re-enable it.

Instead of having ImageMagick request the file itself and do a transform on the result of that request, download the image to /tmp and work off that, using local transforms.

In my use-case, I had to first download the image from AWS S3 (active storage) to /tmp before converting it to a PDF document.

Another challenge I came across with ImageMagick was converting PDFs with any kind of transparent elements. The resulting image would either miss entire sections or have large black/gray elements as overlays. The solution was to add -alpha remove to the convert command.

ConvertAPI

Most conversions to/from PDFs can be done via an external service. The advantage of using a 3rd party API that you don't need to worry about the conversion process, managing PDFs versions and edge-cases or implementing new image formats.

I have had a good experience converting different file formats with ConvertAPI. Their pricing is fair and the API is easy to implement in a Rails project. The ImageMagick version I was using in a project didn't support HEIC images, so I had to use ConvertAPI to convert them to JPEGs.

 ConvertApi.config.api_secret = 'SECRET'

    ConvertApi.convert('jpg', {
        File: ConvertApi::UploadIO.new(File.open(file.path)),
      }, from_format: 'heic'
    ).save_files(file.path)

Using an external service is not always possible though. Managing/testing the dependency can be difficult, performance is not ideal and you might not want to send (confidential) customer information to an external service. In that case, ImageMagick remains a powerful alternative!

Combining PDFs in a Ruby on Rails application

Jerry Weyer — Wed, 27 Oct 2021 16:51:20 +0000

When creating PDFs you might need to combine different PDFs into one larger file, for example if you want to add a cover page to a PDF report you are generating, or if you want to add your general terms to an invoice PDF you are sending via your application.

CombinePDF is a pure Ruby solution to parse PDF files and combine (merge) them with other PDF files, watermark them or stamp them.

Combining PDFs, for example an invoice and terms and conditions, is pretty straight-forward:

  pdf = CombinePDF.new
  pdf << CombinePDF.load("invoice.pdf")
  pdf << CombinePDF.load(Rails.root.join('lib', 'data', 'terms.pdf').to_s)
  pdf.save "combined.pdf"

CombinePDF offers the handy parse method to handle PDFs from a remote location. This can be especially useful when working with ActiveStorage files hosted on Amazon S3 and similar services.

In one of our apps, our users can upload documents that will be combined into a larger PDF. It is not always possible to scan for compatible PDFs during the upload, and we don't want to abort the entire process when an incompatible PDF is uploaded.

CombinePDF offers the allow_optional_content option, which allows you to merge PDFs with optional content sections without raising an exception. We encountered a few instances where uploaded PDFs were not correctly displayed when using this option, but it allows the user to get the final PDFs and assess themselves if they want to replace the PDF in question by a compatible version.

Creating PDFs in a Ruby on Rails application

Jerry Weyer — Tue, 26 Oct 2021 14:25:39 +0000

Working with PDFs in Ruby on Rails can be a daunting task - inflexibility is an inherent part of PDF documents.

As such the best option is to avoid them if possible. Does you invoice really need to be a PDF? Most of the time it can just be an HTML page that the user can save as PDF via their browser. However, it is not always possible to complete ignore PDFs - f.ex. if the invoice needs to be send as an attachment to an e-mail.

You have a few options when trying to create a PDF in a Rails environment. Prawn and Wicked PDF have been around for quite a while. I have been using both gems and they work fine. However, they have a few limitations that can make it difficult to handle more complex PDFs. I recently discovered Grover, which can remediate some of this inflexibility in creating PDFs.

Prawn

Prawn is a pure Ruby PDF generation library that provides a lot of great functionality while trying to remain simple and reasonably performant. It is quick to setup and create simple PDFs:

  require "prawn"

  Prawn::Document.generate("hello.pdf") do
    text "Hello World!"
  end

Where Prawn gets more complicated is when trying to create complex PDFs. It uses its own DSL you need to learn in order to "draw" your PDFs by hand. While the manual is very helpful in order to figure our how to add images, tables and styling, you will end up with a lot of custom code to create a more complex PDF.

There are gems to facilitate handling Prawn PDFs, e.g. prawn-markup which lets you add simple HTML snippets into Prawn-generated PDF.

Wicked PDF

Wicked PDF allows you to serve a PDF file to a user from HTML. As such, you can include your custom CSS and Javascript via the helpers provided by Wicked.

Wicked is a great gem to create PDFs with more complex layouts and styling, without the need to apply a custom DSL. There are quite a few tutorials out there to help you when you are stuck on a specific problem.

One problem I regularly came across with Wicked was that getting everything running in production proved to be more challenging than expected. Especially the custom CSS (with asset pipeline) and images proved to be a problem.

Grover

In my effort to find a replacement for Prawn or Wicked PDF, I recently came across Grover. This gem allows you to transform HTML into PDFs, PNGs or JPEGs using Google Puppeteer and Chromium. It basically imitates the action of a user saving an HTML page as PDF in the Chrome browser.

While there are fewer tutorials out there on how to get everything up-and-running, the great flexibility it gives me to just use my existing views and print them as PDFs makes this my current favourite for creating PDFs.

In fact you can save any existing view as PDF, allowing you to reuse your current HTML and/or CSS framework. You can use Tailwind for your CSS or ViewComponent to display your components and print them to PDF.

However I had a bit of trouble getting Grover to generate PDFs on our Heroku production environment. I finally managed to find a solution in the issue tracker and comments.

For my setup, it was important to use Grover::HTMLPreprocessor as well as include the display_url (make sure to change that in production). You also need to include the correct buildpacks mentioned in the readme.

An example application could include this setup - rendering a view from the controller, including a custom PDF layout and saving it as an A4 PDF with Grover:

renderer = ApplicationController.renderer.new(
    http_host: "http://localhost:3000/"
  )

html = renderer.render_to_string(
  "invoice/show", # Any view within your app
  layout: "pdf",  # You can add a custom layout as well
  locals: { :@invoice => invoice }
)

html = Grover::HTMLPreprocessor.process html, base_url, "https"

Grover.new(html, {
  format: "A4", # Many other options are available
  emulate_media: "screen",
  display_url: "http://localhost:3000/",
  scale: 0.9    # This helped me to get the PDF displayed correctly on A4 format
}).to_pdf

The great advantage of this solution is that whenever I update a component or a layout style, my PDFs will reflect these changes, without the need to modify any PDF-specific resources.

Adding syntax highlighting to a Rails app with PrismJs

Jerry Weyer — Tue, 12 Oct 2021 13:46:27 +0000

If you are running a technical blog, it is very likely that you want to share some code-snippets. Syntax highlighting is nearly a must in order to make any shared code readable for your audience. There are different solutions to integrate syntax highlighting into a Rails application - I'll quickly show how I integrated Prism into this blog.

The first step to get syntax highlighting for your code snippets is to use the correct HTML tags. It is generally advised to add your snippets in a <pre><code>...</code></pre>block.

Next we will add code highlighting with the javascript library Prism. There are other options (like highlightjs), but Prism was the fastest to get running on this Rails blog app.

First we add Prism via yarn package manager: yarn add prismjs.

Then we add the plugin to our babel.config.js and define the languages we want to import:

  plugins: [
    ["prismjs", {
      "languages": [ "css", "ruby"]
    }],

You can find a list of supported languages on the Prism website.

Finally, in order to load the script after page load, we update our application.js:

  import Prism from 'prismjs'

  document.addEventListener("turbo:load", function() {
       Prism.highlightAll();
  });

If your app runs turbolinks instead of turbo, you need to change the "turbo:load" to "turbolinks:load".

This should be enough to get the basic syntax highlighting working! You can now customize your integration:

You can add custom styling by simply overriding the theme styling in your css files, e.g. to change the background color:

  :not(pre) > code[class*="language-"],
  pre[class*="language-"] {
      background: #334155 !important;
  }

You can add custom themes via the prism-themes repository. Add the plugin via yarn add prism-themes and import the corresponding theme in your application.scss with @import "prism-themes/themes/prism-dracula.css";. This blog uses a slightly customizes version of the dracula theme.

How to get Pundit to work with Rails View Component

Jerry Weyer — Mon, 11 Oct 2021 15:06:10 +0000

In facture.lu we use Pundit as our authorization system and Devise for authentication. This allows us to assign each signed-in user a role - admins can do everything, read-only user can only read.

I also included View Component in this project as I noticed in previous apps that it is very difficult to maintain a coherent design over the years if the html and css for each component (e.g. a button or dropdown menu) is not centralized.

After setting up Pundit and creating policies for each user role, we can hide or show different elements based on the current user's role - f.ex. the button to add a new team member will only be visible to admins.

In a view we can simply verify if policy(User).create? and Pundit will call the current_user method to check if the signed-in user is allowed to perform this action.

In a view component, this does not work out of the box however, as a component is generally agnostic about the view context.
As such policy(current_user, User).create? will give you an error:

  undefined method `current_user' for nil:NilClass

Several solutions to this problem are described in issue#310 (View Component). I prefer the CurrentAttributes api solution described by jaredcwhite.

In order to get our current_user to our components, we take advantage of ActiveSupport::CurrentAttributes:

  class Current < ActiveSupport::CurrentAttributes
    attribute :user
  end

In an ApplicationController before_action callback, we set the current user:

  before_action :initialize_component_context

  def initialize_component_context
    Current.user = current_user
  end

In our view component, we can then access the user via the new class:

  Pundit.policy(Current.user, Offer).edit?

In the issue comments, you can read more about how to make it work for previews as well. As I'm not using previews at the moment, I didn't include all the recommendations from the post.