Thoughts on branding, design, writing and life by Kevin Potts. Established 2003.

Webpage Printing: Typography and Usability Considerations

Thinking beyond an extra CSS file by exploring the validity of a separate printer-friendly page, usability concerns and typography issues facing web content destined for the printed page.

As a web designer, either professional or hobbyist, you have no doubt contemplated on how to control the printed output of a webpage as tightly as what appears on screen. There are many articles discussing the technical ends of setting up a CSS-loaded website, and Eric Meyer even offers a specific article on implementing CSS printing into the web page.

But simply throwing in another CSS file for printing is only half the objective. This article does not indulge in code tossing, but instead concentrates on the aesthetic ends of webpage printing, from usability to typography.

Fundamentally, there is no reason not to format a website for proper printing. For content-driven sites, it’s essential—people like to print articles, contact information, press releases and more. For ecommerce sites, it enables the user to print a page more akin to a printed catalog page than what they see on a website. For Flash-driven pages, it’s often necessary to provide better printing outside the Shockwave environment.

From a typographical standpoint, screen reading and page reading are on opposite ends of the spectrum. Providing print-friendly content will keep readers coming back, so the process of adapting small HTML type to a comfortable and well-designed print typeset should be carefully executed. Despite the growing reliance on screen reading, printed material is still preferred by the majority of readers.

Going Beyond the Browser’s Print Button

There are many different paths toward page-printing nirvana, and the means is almost exclusively driven by usability.

For content-driven sites like graphicPUSH, embedding a CSS file into the page is a natural extension of the page’s purpose. There is no need for a user to print the navigation, newsletter sign-up or advertisements when all they want is to print what matters most: the article itself. This eliminates confusion, and saves the user wear and tear on their cheap inkjet printer.

Print-Ready Page vs. Embedded CSS

Embedded CSS files work particularly well for content sites, especially when the text is short and confined to a single HTML file. For articles spanning several web pages, it would be wiser to implement a “print-friendly” page that collects the entire text in one HTML document. (Under no circumstance should the user be forced to find and separately print all fifteen pages of your dissertation on walrus mating rituals. Give them all 6,000 words in one document.)

The separate print page is a mixed bag of pros and cons. Most importantly, it requires the upkeep of two separate pages. Unless content is loaded from a database, the webmaster can anticipate double the maintenance time. For e-commerce pages, however, it allows the designer to style the printed page more closely to a traditional printed catalog. Where the product webpage offered a brief description and a thumbnail image, the print-friendly page can contain a much larger image (or multiple images) and a longer description.

Printing Different Outputs with a Separate Print-Ready File

Whether to use a combination of the techniques is up to the designer. Having an embedded print-ready CSS file used in tandem with a separate page provides a usability cushion if the user prints the first page without realizing there is a better version available. It also gives the visitor more options – in the ecommerce example, they may only want to print the small thumbnail and abbreviated text instead of the glorified version.


Then there is the PDF format, which is the “printer-friendly” button taken to the extreme. While this can be a point of contention among some usability experts, I feel every technology has a place. Within the inflexible realm of the PDF, the designer has unlimited typographic and placement control, and can tailor the output to a tight specification. This is particularly useful when publishing content under a constraining style guide.

What it gains in design capability, however, PDF loses in usability. Loading a document requires the Acrobat plug-in (admittedly installed on about every machine in the world), which takes entirely too long to launch the Acrobat application, which then has to load a memory-heavy file (anywhere from 30k to 50MB), which is terrible to read on screen and slow to print. If used, the PDF link should be clearly marked “PDF,” and the link should specifically open a new browser window to avoid interrupting the browsing experience.

Condensed PDF Tips:

  • PDF should be secondary to an embedded CSS file and supplementary “print-friendly” HTML page.
  • Clearly indicate if a link will launch a PDF.
  • PDFs should be set to open in a new window, not inside the user’s current window.
  • Use with discretion. Best applied to longer documents (white papers, technical manuals, etc), forms and archival material where typographic control is a necessity. Absolutely not recommended for screen reading.

For Their Eyes Only

What the user needs to see printed and what they need to see on screen are two entirely different things. They visit a site to read content, scan related material, explore links and poke around different sections. When a user prints a page, it’s exclusively for the content.

Extraneous items must be removed. For example, the following should not be printed: any navigation, header graphics, banner ads or other advertisements, superfluous pictures, and background colors or images. If possible, complex heads and subheads in the content should be replaced with simplified text, and any peripheral information like copyrights and legal disclaimers should be kept to an absolute minimum.

What Should Print

CSS and server-side scripting also allows for some interesting tricks. For instance, hyperlinks are useless when printed, but can be more useful when the actual address is printed after the link. In the print-ready CSS file, simply insert the following code:

a:after{content:" [" attr(href) "]"; }

This will display: graphicPUSH[]. This technique only works in CSS2-compliant browsers such as Opera and Mozilla. Older and inferior browsers like Internet Explorer and Netscape 4.x simply ignore the tag.

If the links are not a critical part of the content, consider making them appear the same as the rest of the text. Remove any decorations (like underlines) and indicative colors. Be careful to semantically embed links into the verbiage, or the multiple “click here” phrases will seem out of place when the page is printed. (“I went to see some cows today” makes much more sense than “click here for the cows I will see” on the printed page.)

Typography: To Serif or Not to Serif?

There is no mystery about the differences between reading materials online and reading the same text on the printed page. In screen reading, studies have demonstrated a consistent 20-30% speed decrease, increased comprehension errors and a tendency to “scan” documents quickly instead of properly taking in the information. The reasons for these deficiencies are many; inefficient web writing, people’s natural impatience with computers and increased eye and neck strain are all working against web-delivered content.

As a web designer, there is little that can be done to alter human being’s natural physiology. Yes, we can write better for the web. No, we cannot hack eyeballs to adapt better to flickering screens, low resolution type and perpetual eye and neck discomfort.

However, if readers want to print an article from our web pages, we have the opportunity to present our content in a much more comfortable medium.

For blocks of copy, sans serif fonts work better on screen, serif fonts work better for print. It’s as simple as that. There are very specific reasons why The Times of London has used Times New Roman for seventy odd years, and why just about every site uses Arial or Verdana for body copy.

Sans serif fonts can work well in printed body copy if they are clear and natural to read. However, because they lack a serif font’s small hooks and ornamentation that guide the reader from letter to letter and word to word, they have to be printed a little larger than their brethren for maximum readability.

If your site uses a serif font like Georgia or Times New Roman for body copy (not recommended), it would only be natural to extend that to the printed page. For sites that use sans serif, they are at a crisis of identity: submit to the superior serif and water down the site’s look and feel, or use a sans serif to carry the identity to the printed page?

For, I chose the latter, but with some changes. The Verdana face is bumped two point sizes to 13px, and the leading (space between lines) increased as well. This maintains clarity and provides consistency in brand.

The eye works better when it can absorb short lines of copy. Generally, a 40-character width is ideal, since it’s easy for the eye to scan across and then back down to the next line. graphicPUSH’s page width falls around 50 characters, but combats the extended length with generous leading that allows the eye to find the next line with relative ease.

When developing the print-media CSS file, I brought in the “content” div width to 80% and increased the left margin. This structures the copy in a tight, centered column for easier reading and prevents words and images from falling off the right edge, which often happens when printing from a browser.

Condensed Typography Tips:

  • Sans serif for screen body copy, serif for printed body copy.
  • Keep column width tight (40-50 characters ideal).
  • Simplify headers and subheads. No background tints or borders.
  • Use point sizes in defining the print-media CSS definitions.Relative sizes are unnecessary since the permanent nature of the printed page dictates fixed measurements.