In trying to track down the cause for the printing bug that’s been harassing me lately, I’ve been simplifying the printing code as much as is possible. In the process, I’ve been cleaning up and evaluating the different implementation details. What functionality, for example, is absolutely necessary when implementing both print preview and general printing support? What’s required to print to multiple devices, such as both a printer and a PDF?

An Interface for Printing Documents

In my trimmed-down version of the print preview component, I’ve tried to eliminate everything that’s unnecessary and cleanup the supporting code. I ended up with the following requirements which form the IPrintableDocument interface:

• nextPage, previousPage – Switches pages in the document
• validNextPage, validPreviousPage – Indicates whether or not there are more pages in the document
• moveToFirstPage – Switches to the first page in the document. Though perhaps not as obvious, if you’re previewing the third page in the document and then choose print, it’s nice not to have to iterate through every page in the document to start printing.
• desiredWidth, desiredHeight – Specify the desired height and width of the document. By specifying 850×1100 (W x H), you indicate that you want a document that has the same ratio as an 8.5″ by 11″ paper, or standard letter size paper. By changing the desired width and height, you could just as easily represent the same ratio as an A2 or A4 size paper. The print engine takes that document and scales it down or up to fit the page. This also serves as a good way to decide how large the document should appear. It’s kind of like deciding between 800×600 or 1280×1024 with a fixed size monitor. The larger the resolution, the smaller everything appears in the document. For us, it turns out that 850×1100 was perfect for letter size paper, giving us a good amount of content without cramming thousands of characters into a single, not-so-respectable line.
• validateNow – Force the redraw of the document after changing pages, etc.
• width, height – When scaling the document to implement zoom, these represent the actual width and height of the document. Generally, desiredWidth and desiredHeight are used to calculate scaling ratios are used when it’s easier to set the width and height directly rather than scaling the document to the correct size.
• x,y – These are the x and y coordinates of the document within the parent container or on the print out. I use these when moving the document around within the print preview.
• scaleX, scaleY – Scale the document in the X or Y direction, respectively. I always set the scale in both directions to maintain the aspect ratio of the document. This is used frequently for zoom and the final printout.
• rotation – Rotates a document, if necessary. After the user clicks on the print button and the print job has been started, the printer dialog pops up, asking the user to choose the printer. Within that printer dialog, the user has the ability to select the orientation of the page. If they select an orientation that does not match that of the document, the document must be rotated by 90 degrees, either clockwise or counterclockwise, to make the document correctly fit on the page. One thing that I found quite annoying was that unless you embed fonts, when you rotate a document, the fonts disappear.

One thing that I do not have in this interface is totalPageCount. It’s not completely necessary, but could be beneficial. Right now, if we want a page-count indicator we perform all the calculations internal to the document; the print preview is completely unaware of the footer changing or doing anything special. However, it would be nice to have a “GoTo Page” option on the print preview, in which case it would be useful. It would also be useful to have a “GoTo First Page” and “GoTo Last Page” options, which are also not implemented, but which could be easily implemented. Right now, the print preview would have to iterate over the document to determine the number of pages.

Supporting Different Devices with Print Engines

When implementing PDF support using AlivePDF, I noticed that we really needed a print engine interface. When dealing with PDFs, or “printing” to other non-printer devices, they don’t need any knowledge of the PrintJob, because the PrintJob is strictly for printing to a physical printer. So, I created a print engine interface to allow other engines, such as a SaveToPDFPrintEngine, to be easily created and used.

Miscellaneous Details

Once the document is complete, and represents a page that should be printed, it’s only necessary to scale the document so that it will fit on the page, and then tell the PrintJob which area of the document to print. Despite having scaled the document, the area of the rectangle must be represented by the size of the unscaled document, thus I use desiredWidth and desiredHeight.

You can take a look at the revised version here or download the source here.