In short, this habit annoys me.
Print-only page audience
Other than printing, there’s one other reason to visit a print-only page: to click to an un-paginated article. I’m a fan of pagination, but not if it requires me to load a series of brand new pages; a solution like the one used for several years on iht.com is far preferable, to a point.
The result is that I, like so many other people, will click over to the print-only page for the benefit of making one single page request more, rather than three or more.
The point is that print-only pages get a lot of online use, because I know I’m not the only person who feels hostile toward excessive pagination.
…Which leaves us with bad and thoughtless typesetting
The practice of producing print-only pages with static column widths and auto-leading is, in short, a bad one.
Auto-leading on long pages underscores the best reason for pagination, namely avoiding the discomfort of keeping one’s place in the copy while scrolling.
However, I don’t believe that oversight is intended as a disincentive. Someone probably believes that auto-leading will conserve paper, but decreasing leading on magazine articles won’t conserve that much; increase leading by one-sixth of a line and, if you’re using twelve-point type, you reduce the number of words that can fit on a page by 60 or so (15%). Assuming stories of 500-1,000 words and plugging in this metric, auto-leading suggests that most of your stories will print across two or three pages.
Where does this leave the cutoff?
Pagination points in words for stories printed with 12-point bodycopy, with and without increased leading Page Auto-leading + 1/6 1 400 340 2 800 680 3 1,200 1,020 The conclusion that can be drawn is that the only common story length likely to cause paper “waste” as a result of an increase in leading is 700-750.
Unless 750 words is a happy place in your editorial guidelines, why not increase leading on the print-only pages? Your visitors will love you for it.
Fixing the column width in pixels is an inconvenience to those who use text zoom rather than page zoom.
Once Firefox 3 (which will support page zoom) ships, this concern will go away. In the meantime, it’s a pain to see my words-per-line decrease when I increase the type size.
If ’twere me, I would:
- Link a stylesheet of
type="print,screen”
- Create both
@screen
and@print
blocks in that stylesheet - Emplace
width: 50em;
in my screen bodycopy rule and no width attribute at all in my print bodycopy rule (which will allow the copy to occupy the full width of the printed page).
…Why a line length of 50ish ems?
50ish ems often translates to twelve or thirteen words, which is at the low end for optimizing the legibility of long passages of text. That approach also allows for fully justified margins, which for all but the longest paragraphs convey the idea of higher production values. Especially long pieces should avoid justified margins, however, as the ragged right margin eases place-keeping.
The alternative is to allow the lines to run completely across the screen in both print and screen media, which at higher pixel pitches will improve readability at the expense of legibility.
- Link a stylesheet of
This is all rather pie-in-the sky thinking, and when I look at my most recent print-only ruleset I see that I let the bodycopy run across the breadth of the page — you could say that I’m thinking this through for the first time.
No comments:
Post a Comment