Howard Finberg, the executive in charge of pagination at the Phoenix Newspapers Inc. (The Arizona Republic, The Phoenix Gazette), is fond of saying that "not every page can win an award." He uses this to illustrate the conundrum of whether you should hire a mechanic or an award-winning page designer to be your paginator.
Finberg, whose papers have been fully paginated (text, rules, images, ads) since 1986, says that if you hire only designers, you must address this question: "Who does the weather page?"
His solution is to build a cadre of paginators from both walks of life and rotate the humdrum activities such as the weather page among them.
Actually, though, it's time to start thinking about letting the computers themselves design some of the more formatted pages, including the weather page.
Many newspapers have already fully automated some of their pages--as long ago as 1985, some papers outputted stock tables as whole pages. The introduction of products such as the Associated Press' Grand Central Stocks and Tribune Media Services' TMS Stocks have allowed editors to come close to "pushbutton" stock pages.
And many newspapers have effectively automated the weather page problem by buying a package from a third-party supplier, such as AccuWeather or WeatherData. These companies will transmit the entire weather package--graphics, text and tabular material--to a paper in QuarkXPress format.
But I'm looking for something a little smarter than a program that can build highly formatted pages. My vision is a collection of software that will build many of the common pages that are found in today's newspapers.
For example, let's take the advertising dummy of a page: There is a four-column-by-20-inch ad in columns one through four and a group of small ads in columns five and six that square off at eight inches high.
When the slot editor sees this page, she would immediately see that there's not much room to be creative here, so she would shuttle it off to the automatic page-dummying system, first adding a couple of story slugs and a picture slug.
The automatic page-dummying system would open up a database of pages that were exactly like this--the same ad stack, two stories and a picture. The software would know that your paper's design policy is to boost up any ad taller than 20 inches and put a plugger underneath. It would read the length of the stories and determine that the longer story should be at the top of the page and the shorter story at the bottom. The picture dimensions would then be read, and with all these things in mind, the software would pick a design out of the database and attach the correct slugs to the editorial components.
Then the automatic page-dummying system would return the page to the slot editor, who would review the work done by the system and maybe make some minor adjustments. At this point, the slot would send the page to a copy editor, who would write the headlines and cutline--and maybe trim a few lines here and there to make the page actually fit. Upon completion, the copy editor would return the page to the slot editor, who would back-read the heads and cutline and send the page to film.
I could see developing a system like this for the Macintosh because of the easy interapplication messaging, and there's also no reason that this hypothetical scenario wouldn't work under Windows or UNIX.
In fact, this would be a relatively easy system to build. A newspaper could even design one for itself.
For the Mac, the development environment could be AppleScript or Userland Frontier; for Windows, Microsoft's Visual Basic, and for UNIX, Perl.
These development environments all support a certain amount of interapplication messaging and would therefore allow even an amateur programmer to send the shape files of the ad dummy back and forth, as well as communicate story lengths, picture dimensions and slugs. Some of the environments would work better than others (both Visual Basic and Frontier have databases built directly into the programming system), but there is no question that with some tinkering, such a system could be built by most any newspaper.
But why should two dozen newspapers nationwide invest a lot of time and effort in such a project? Our suppliers should develop it! (Any takers?)
It would seem to me that such a system would make a company's pagination offerings much more alluring. The efficiencies such a product would bring to paginated newsrooms might even allow paginators to have the time to read some of the stories before they place them on the page.
Then, maybe, every page handled by a human could be an award-winning page.
Cole is a San Francisco-based newspaper consultant and is editor of The Cole Papers, a monthly newsletter on technology, journalism and publishing. E-mail, cole@plink.geis.com; phone, (415) 673-2424; fax, (415) 673-2449.
©1997 Newspaper Association of America. All rights reserved.