The Sad State of Printing on the Web
Kyle Kemp

Just wanted to add my note of sympathy. I’ve also built something similar: a web app that generates a couple of sizes of front-and-back “flash cards” with individuals’ headshot photos on the fronts and their name and bio on the back (for the professors and admins at my university job who want to memorize their students’ names before the first class day). Basically the same trouble of needing to align the fronts of the cards with the correct info on the back. Print CSS support is the work of the devil.

Aside from the seemingly ancient CSS rules (and bugs) that affect each browser’s print rendering, there’s also the problem that the underlying print technology itself is different between operating systems (GDI on Windows, Quartz2D on OS X) so you might run into compositing inconsistencies; things come out different depending on which printer you’re trying to print to (the fancy drivers for the giant office workhorse printer might be “fixing” the size of your print for you via some advanced setting, compared to the cheap deskjet that just does what the user’s specified on the basic panel); the havok that selecting the “scale / shrink to fit page” checkbox in the browser’s print panel can wreak (good luck telling all of your users which option to select for consistency); not to mention when users try to print to paper sizes that you’re not expecting (8.5"x11" is our standard, sure, but even in our building we’ve got folks who love their legal-sized paper).

I haven’t done much research or testing, but *maybe* it’s worth reviewing the changes that have come in CSS3's Paged Media spec? Specifically, there are new “at-margin” rules about how margins are defined within the at-page blocks. Given browsers’ support of CSS2.1 paged media handling, though, I’m not holding my breath that the new specs are handled consistently either…

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.