When wearing this hat I don’t print very often. When I do it’s almost always to produce a paper receipt, and very occasionally to create a dead-tree version of some HOWTO or other documentation. The biggest problem here is that I only want to print the relevant part of the page, but I invariably end up with ads and site navigation links taking up space on the page. Usually the relevant part gets chopped off, or split across pages because it’s been pushed out of place by the extraneous crap that surrounds it.

What I’d like is a means to crop the page: the ads and links almost always take up space at the sides and the top of the page, so a simple rectangular cropping tool would suffice for most sites. Just let me drag a marquee around the part of the page I want to print, and crop everything else. Simple but effective.

At the moment the closest thing I’ve found to this is to use the Aardvark extension for Firefox which lets me selectively delete items from a page and remove any artificial width restrictions. This extension works well if you know something about how web pages are structured (the tree structure of the DOM), but could be a bit confusing otherwise (if you don’t know what the DOM is, then you probably fall into the latter category). It also works on the screen version of the page, which might not be the same as the print version (though it usually is). The cropping tool I’d like to see would work on the Print Preview screen, giving you a better idea of what will actually come out of the printer.

As a user I often want the header and footer that my browser creates. With this hat on it’s useful to have a record of the original URL, and a timestamp. However URLs can be very long, and some browsers simply truncate them. Why does it even have to go in the header or footer: if I’m printing in portrait mode then having the URL running up the side of the page (the long edge) would be acceptable on receipts. How about a choice between wrapping long URLs, truncating them or printing them along the edge of the page rather than in the header or footer?

I write web-based applications for a living – usually for deployment on a company’s intranet. There are many advantages to a web-based application, not least of which are centralised management and ease of deployment (you just have to send the users an email with a link to the application).

Web apps have become more and more sophisticated over the years, but in doing so they are really starting to show the limitations of the current crop of browsers when it comes to printing. Consider a web-based word processor: this is an obvious example of a web app that is broadly achievable with today’s web browsers, but who wants to print a letter to the bank manager which has a URL and timestamp emblazoned on it?

As a developer I’d like a way to turn the browser’s header and footer off. As a user I often want them on. The solution, it seems, would be to provide a way for a web page to indicate that it really would like to have them turned off, but for the user to easily override the setting. The user could have an option to always print them, never print them, or turn them off when a site requests it. A more advanced system would allow white- or black-listing of sites which can turn them off.

The next requirement in a web app, after turning the browser’s headers and footers off, is to turn your own headers and footers on. Again consider a word processor or desktop publishing program: there needs to be a way for a web application developer to add headers and footers that are printed on every page, irrespective of the amount content, the size of the page, or the page margins. The browser knows where its page-breaks will be, and it should be able to work backwards from that to allow enough space for the footer, and work forwards to insert the header.

In fact there’s a whole CSS specification that deals specifically with paged media (i.e. printing and slideshows) and which should, in theory, allow developers to specify repeating content for each page and other such tricks. Alas, such features are poorly supported by current browsers, and even if we could specify our own headers and footers the advantage is rendered less useful until we can also request that the browser’s own inclusions be supressed.