Move printing rasterization from pdf opener

Right now, if you try to open a pdf in your browser on the desktops, it proceeds to download it, and run raster on it. This process takes 10 seconds to 1 minute, depending on the length of the pdf file. This is quite annoying, especially when you are opening multiple pdfs to see which one you want to read.

My proposal for solving this:
On each desktop, run a cups server. This cups server would have a filter that runs the rasterization, so you would only rasterize a file if you submitted it for printing. The cups server on the desktop would have a filter that runs whatever rasterization, and forwards the file onto printhost for printing. This would allow removal of the code that disables the in-browser pdf viewers, and the pdf-open wrapper for evince.

This would be better than the previously tested solution of moving all rasterization onto printhost, which caused huge delays for printing, as cups is single threaded.

The changes that would require would be in the ocf::packages::cups class. /etc/cups/client.conf should be change to contain “localhost” instead of “printhost”. There should be a configuration file starting a print queue, with a filter to do whatever rasterization is necessary (possibly by creating it from the command line and copying the resultant file into puppet). Some other puppet commands should also to be added to ensure that the cups server is running. One might also be able to remove any remaining rasterization on printhost.

1 Like

This is an interesting approach. I still think it’s worth investigating the “broken” PDFs more closely to see if we can find out what’s wrong with them and implement a more fine-tuned fix. But this definitely has potential too. Perhaps this would also solve the Google Docs printing problems as well.

It’s been a while since the last post on this thread, so I might as well chime in now…

TL;DR: I’ve been working on this, with the help of fydai and others. So far we’ve made a basic setup and drafted most of the Puppet code needed. I haven’t committed yet to Github since there are a few details I want to finish off, but all current work is in the puppet environment fydai_printing_sucks.

What has been done

I’ve mostly been following fydai’s original proposal, where we run a local CUPS server that feeds PDFs through a rasterizing filter, and then sends it to printhost. Here are some specifics:

  • Locally, we set up CUPS to have two printing queues, single and double. These two queues, respectively, connect to the printhost classes single and double via an ipps connection.
  • We install Tea4CUPS, and specify in the configuration settings that printing jobs should first be fed through a rasterizing filter (described below). Using Tea4CUPS allows us to easily wrap our rasterizer around our printing setup, instead of doing it through CUPS itself. (I have tried the latter, but a few OCF staffers have commented on the inelegance of my approach.)
  • The rasterizing filter is modeled after the pdf-open script (described here), and uses the convert program to create a lower-density PDF, essentially creating a “rasterized” version.
  • I’ve also discovered that convert sometimes needs more memory than given by its default limit, so ImageMagick policies (convert is an ImageMagick program), specified in a policy.xml file, need to be changed. However, if there is a better way to resolve this issue (e.g., command-line options to convert to have it use more memory than usual), I will look into that as well.

I haven’t done extensive testing, but I have been able to successfully print several documents, including some PDFs known to cause issues in the past (see RT ticket #4839).

Todos

While I have written Puppet code to integrate CUPS, Tea4CUPS, and relevant files and setting needed for the basic setup, I still need to find a way to deal with the ImageMagick configurations, as mentioned above. Additionally, I will need to take another look through everything written, double checking the overall design and cleaning up any debug or otherwise irrelevant code.

After doing so, I will finally need to disable keur’s setup for rasterizing files upon opening PDFs.