- Home Page
Categories
Archives
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- June 2011
- May 2011
- April 2011
- February 2011
- January 2011
- December 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- February 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- June 2006
- May 2006
- April 2006
- February 2006
- November 2005
- October 2005
- September 2005
- June 2005
- April 2005
- March 2005
- February 2005
- January 2005
- December 2004
- November 2004
- October 2004
- September 2004
- August 2004
Author Archives: tim
Forty Two
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?
42 Image from Answer To Life / CC-BY-SA
Posted in General
Leave a comment
