Being Friendly Towards Printers

Why bother?

It’s a long time since media=“print” was introduced to the world; but still, few seem to have been embracing the technology.

The reasons for not including a CSS-sheet can be many. First off, it’s usually enough hassle to get one design finished by the (usually thight) deadline - little less three (screen, print and handheld). Then there usually are serverside scripting that can create a ‘Printable version’ and hence sparing you the trouble.

And since most people who’s been online since the nineties, is usually used to looking for that ‘printable version’ - and there’s usually no way to see if the page will come out just fine if you just press the browser’s ‘print’-button.

I usually have to check the source code, to see if there’s a media=“print” in there somewhere, before I print something. And even if there is, that doesn’t guarantee that the page will turn out good - as many designers put the <link> in as a placeholder for (and perhaps a reminder of) the CSS Print sheet they are going to make, once they get around to it...

The benefits

So why, then, should media=“print” still be the way to go for online printing?

There are two facts that needs to be established first of all - and it still amaze me how many doesn’t get these:

1. People needs the ability to print text!

   If a text is more than approx 100 words; people are going to want to print it. Online reading is hard on the eyes, and for desktop users - more difficult to bring to bed.

2. People have different needs for online and offline reading.

   Online, people do not spend a lot of time in one place, that means you must provide something to catch the visitor’s interest... When people take the effort to print something, however, they probably have some interest in the content of that page. That usually means half the stuff in the online version is no longer nessecary.... (Also, they’ll want the ability to make notes in the text.)

And usability-wise, there should be a standarized way of printing documents online. And that should be the browser’s ‘print’-button; not some ‘print this’-button!

What not to print

In a CSS sheet for print; display : none; is your best friend. Stuff like navigation, interactive elements and most of the graphical elements of the page isn’t needed. Graphical elements are usually too low-res for print anyways; as the resolution of the screen is 72dpi; and the resolution in print is 300dpi.

So the first thing you should probably do in your CSS, is remove everything you don't need... In Twisted Intellect's stylesheet, that looks like this:

.hidethis, .screenonly, .palmonly, #accessibility, #comments, #commentform, #etc, #header, #navigation, .search {
display : none;
}

Now, note that I've added a few special classes to that list: .hidethis, which I include a display : none; for in all of my stylesheets. This I use, for instance to add a notice at the top of the page, telling users to upgrade their browsers, if they don’t have a CSS-supporting browser.

Then there are the classes .palmonly and .screenonly. Now, this is also quite self-explanitory; and as you might have guessed, there’s also a .printonly class, that’s included in the other stylesheets.

Readability

The one golden rule for print, should be readability. The reason people mostly print online articles, is because they are too long for online reading; and they want to print it so it’s easier to read.

That leaves you with some very important choises in regards to typography. Serif versus sans-serif, font size, line-height and kerning, for instance. Then there are the choises you have to make regarding layout; how wide margins do you need, how much text should you try to fit into each page et cetera.

Basic decitions

The first choise you have to make is what type to go for. While serifs are widely regarded as most efficient in regards to readability; it’s somewhat crippled by the lack of control you have over what fonts the user will have installed, and even kerning rendering. Additionally, many designers will feel that a sans-serif is going to fit the online design way better than a serif font.

While you may be used to doing printjobs set in Garamond or Palatino, for instance - very few non-designers are going to have these typefaces installed on their computers - even if they do, you have very little control over how CSS handles the kerning, ligatures and so on.

However, sans-serifs are even worse. We all know that sans-serifs are less readable in body type and kerning errors are way more obvious.

Size matters

As for size, there is a wide perception that the body text should be in a relatively large fontsize. I don’t nessecary agree... This is a choice you should make by looking carefully at your audience. What is true, however, is that CSS gives you a lot more freedom to make your choise based on what your audience needs.

As you already don’t know how long the text is going to be, and you have no obligation to fit the text into X number of pages, you can (in theory) choose any fontsize you want.

But that doesn’t mean “choose 24pt for body print and let the user pay for the ink”. It means that you should have the text as your users are going to want it to be. If you’re targeting an audience aged 60+ for instance, you are going to want to have a larger textsize than if your target audience is young and with good vision (like webdesigners?)

So, that means my body text is going to look like so:

font: 8.5pt/1.5em Palatino, 'Palatino Linotype', Georgia, Times, Times New Roman, serif;

Notice I’ve put a line-height of 1,5em (150%). That should be enough in most cases, but there’s no harm in expanding that value to 1,7em for instance.

Additional adjustments

There are only two more settings I’ve changed in regards to the body text - and those are:

letter-spacing:0.3;
text-align:left;

Now, as I said before, left to itself, the kerning is bound mess up somewhere... Because the user doesn’t have the fonts, because the printer does something wrong or simply because the browser renders it wrong. So the smartest thing is in fact to play it safe and add a little extra - 0,3em to be exact.

It’s also a common misperception that justified text is a good thing. However, justified text has the possibility to really mess up the typography... One thing is using it sparingly in print designs where you have full control over the text, or in cases where it’s absolutely vital to the design.

But unless your design really depend on a justified textarea, it should probably be avoided.

Wide margins

The most annoying thing about many print-versions is that they do not provide you with enough margins.

My stylesheet has the following values:

body {
   margin: 23mm, 27mm, 35mm, 27mm;
   font: 10pt/1.5em sans-serif;
}

#article {
   width: 80mm;
   margin-left:13mm;
}

Now, this means a lot of margins all around; and the main article no wider than 8cm... Now, the reason I have the margin-left on the #article is because I want to add the site logo on top of the page, and I want the article to line up nicely with that one... And the margins on the right-hand side of the body is there in case I want to add more elements later on.

The seemingly huge margins have several important functions. It provides a lot of readability, it lets the reader make his or her own notes directly in the text; one of the great advantages of the “dead-tree-stuff”...

Headline

#article h1 {
   font: bold 13.5pt/1.5em 'Myriad Pro', Myriad,
   'Helvetica Neue', Helvetica, Arial, sans-serif;
   font-stretch:condensed;
   text-transform: uppercase;
   letter-spacing: -0.01em;
   white-space:nowrap;
   word-spacing:-0.07em;
   overflow:visible;
}

Puh! That’s one big chunk of code..! Now, let us go through it one bit at a time...

The first part should be pretty straightforward. I wanted a light, but compact headline - and so I went for a sans-serif - hopefully Myriad or some sort of Helvetica - but at the very least Arial.

If possible, I also wanted it to be a bold condensed - and I wanted to set the entire thing in uppercase.

Partly to weigh up for the lightness of a possible ‘condensed’, and partly to give it some extra slimming when the ‘condensed’ doesn’t kick in - I’ve added some minus-values for both kerning and word-spacing...

I have no need for the headline to break in the same way that my body text does, at 80mm, so I added a nowrap to let it run beneath the bounderies of the body-column.

 

Then there’s the H2. A lot of my articles use subtitles within the article - like this one; and I want to give them a little love as well...

#article h2 {
   font: 11pt/1.5em 'Myriad Pro', Myriad,
   'Helvetica Neue', Helvetica, Arial, sans-serif;
   font-stretch:condensed;
   letter-spacing:-0.02em;
   word-spacing:-0.07em;
}

Nothing much to say about this one; it mostly follows the example from the H1, only I’ve removed the boldness, and hence added a little thighter kerning - and I let it run in it’s natural case.

Other text-elements

Then I wanted to add some extra styling to the first paragraph of the text - the only problem was; I didn’t want to give it an extra class. So it was time to bring out the more fancy selectors...

#article h1 + p {
font-weight:bold;
}

As for em and strong there is no need to do anything special, besides the usual italic and bold formatting; so I hasn’t added any rules for those two. What I did want to do something special about was the blockquote:

#article blockquote {
   width: 55mm;
   padding-left:2mm;
   border-left: 2pt #cf8183 solid;
   font-style:italic;
}

Now, this gives me a light red border to the left, some padding and a makes it a bit narrower than the other text. The red is also nice in the way that it turns out as a light shade of gray on grayscale printers.

The dreaded links

Links are by nature interactive elements - and hence loose some of their functionality in print. That makes them one of the most difficult issues in printing online material.

So, how do you tackle it? There are several ways, actually... One solution; which I do not reccomend is just add some basic styling to it; like you would when designing for screen:

#article a:link, #article a:visited {
   color: #900;
   font-weight: bold;
   text-decoration: none;
   border-bottom: 1px #900 dotted;
}

Now, first of all, links printed like this has no meaning whatsoever. Yes, you are able to distinguish what, in the text, are links and what are not. But you still have to go online to see where the links lead...

Luckily CSS2 comes to the rescue with the introduction of CSS include...

In the ALA-article “CSS Design: Going to Print“>Going to Print”, Eric Meyer introduce the following code snipplet:

#article a:link:after,
#article a:visited:after {
   content: " (" attr(href) " ) ";
   font-size: 90%;
}

What this does, is add the URI to the link in parantheses; at 90% of the normal textsize...

Now that we have given the links some more meaning, we’re able to keep some of the styling for the links...

But there are still some issues we need to adress. First off there is the color. We need to be sure that the link is equally emphasized in both color and grayscale output. That means the #900 has to go; and in comes black.

Then there is the underlining. Most printers and/or browsers have severe issues with both the dotted-style and the border-bottom-way of doing things. More often than not it comes out crippled, and sometimes not at all.

That means we’ll probably be better off going for a more standarized text-decoration : underline. And that leaves us with the following code:

#article a:link, #article a:visited {
   color: black;
   text-decoration:underline;
}

Ok, so that’s a fairly simple way of doing it - and in CSS1-browsers the technique is simply not recognized, and the user will simply see the links as underlined pieces of text. Just enough to remind them that it’s links, without disturbing the reading process.

However - this technique has some disadvantages. If you have a lot of links in a text; all those URIs will soon pose a major readability issue... But guess what? There is a way!

There is a way to build a DOM-script that collects all those URIs and puts them in a special section as footnotes. There is a whole article dedicated to the technique over at ALA, by Aaron Gustafson.

However, there are some negative issues about this technique as well; First of all; the script adds things into the document, that you will have to hide later on from the screen edition, via CSS. Though there already are some of those items in the code already (remember .printonly) I’m not very keen to add any more of them. Then there are the users that have JS turned off.

That was enough to make me choose not to use the DOM-method for the time being - but by all means; go check it out!

Letting the users know

Then there is the thing about converting all of those users that are still looking for the ‘Print this’-button.

You need to tell them, as simple as possible:

If you just press the browser’s ‘Print’-button, the page will turn out just fine!

The easiest way of doing so, is actually by putting that text in the same place on your page, as you would normally put the ‘Print this’-button...

Another, slightly more advanced way of doing it would be to add a OnClick window.print()-link where the ‘Print this’-button would normally be. I already covered that in a previous article, so please feel free to use that technique as a reference.

Personally, however, I feel there is no need for more than one print-button (the browser’s, that is...)

Further reading

Feel free to take a look at CSS/storyprint.CSS” title=“Take a look at my CSS sheet for Print”>my stylesheet for a little example of what I’ve been talking about. Other good reads on CSS for print are:

• Mark Boulton: Printing the web
• Eric Meyer: Print Different