Is it a coincidence that PaperCut currently supports 42 printer description languages , that I am turning 42 years old this year and, as we all know, 42 is the Answer to the Life, the Universe and Everything ? Yeah, it probably is :-)
Since joining the PaperCut team, I have mainly been working on the area of PaperCut responsible for the analysis of print jobs.
I have come from a background of programming in the computer language, C , doing file system programming in the Linux kernel . I worked for SGI on the XFS file system team. The job analysis code in PaperCut is entirely written in C which has given me a chance to sink my teeth into something quickly. Luckily for me it is also well written C code and has been designed to be easily extended for new print languages and print drivers.
Every few weeks printer manufactures release new print drivers and these need to be tested with PaperCut. Changes are always occurring. Sometimes these changes are minor and just a little bit of tweaking is required, while others are a lot more complex. In some cases we need to support whole new print languages.
Many of the lower cost printers these days are using GDI drivers . These are drivers that don’t support known popular standards like PCL or PostScript and implement their own protocols - often not documented nor following any existing standard. In order to handle new GDI printer languages, it’s a bit like playing a game of detectives. By reverse engineering, we try out various sample documents, changing different page attributes and work out how the driver encodes the various attributes (e.g. duplex, gray-scale and paper-size). We have a set of pattern tools and a few techniques that help us perform this decoding process. After a bit of teeth pulling we develop an algorithm to support the new driver. The techniques are in some ways similar to those implied in reverse engineering file system formats!
After we’ve made changes to our print analysis code, we run our analyzer tool over a corpus of over thousands of real-world documents to ensure we haven’t introduced any regressions (steps backward). The tools also check for memory leaks and test performance against previous test runs to make sure the software is not getting slower.
I hope you’ve enjoyed the behind the scenes look into some of the technical workings here at PaperCut. For a less technical look, make sure you check out what print management has to do with Coffee?