Desktop publishing: changing the way you work

Folio: The Magazine for Magazine Management, May, 1989 by Alex Brown

Many of the mainstream page make-up packages now have a style sheet facility. These allow you to embed logical statements in a word processing file. When the text is imported, the style commands trigger typesetting specifications that have been previously defined for a publication. In general, the style sheet idea allows editors, who are best able to make judgments about the classification of text elements, to identify them usefully without having to learn type specifications and mark-up. The designer defines the specs in the page make-up program itself. The editor simply adds a style tag to the appropriate text. If anyone wishes to change type parameters, he redefines the style, which immediately affects all text with the tag of that name.

The task of keyboarding the line "@SUBHEAD =" and so forth is easy to transfer to a word processor's macro facility. One might write a macro that was triggered with the control-S key, or use a key utility to hold text strings that explode from a single keystroke. Some codes are best embedded by a search and replace routine. Many word processing format commands pose problems for the page make-up software that will next handle the file. For example, double-space commands need to be removed, and underscores may need to be converted to a different command to yield italics. In any case, the actual typing aspect here is not truly daunting. However, editors may feel that it is. And they may be correct in wanting to avoid some or all of this coding.

First, a typing error may foil our hopes of greater productivity. Some errors can be fairly tough to unscramble because we've just made editors the only people expected to examine the content of the text. A page layout artist won't be able to determine if anything is wrong because he's never been asked to apply type specifications by looking at the text. Further, software developers have almost always implemented the style sheet convention for whole paragraphs. A carriage return signals a potential opening for a new style tag; if the program doesn't encounter one, the previous tag continues to govern the text. This means that styles cannot be changed within paragraphs, and that any time one deletes a hard return, even in the page make-up program, a style tag may be extinguished. Think about the disturbing consequences and the logical limits this places on an editor's coding.

Next, we'll need codes to handle some special characters we expect in type but can't find on a keyboard. Ventura, for example, will provide an em dash if you type 197 inside "greater than" and "less than" signs in a word processing file; PageMaker 3.0 will convert double hyphens to em dashes automatically, but it makes distinctions between minus signs, dashes and hyphens, so you may have to experiment with your word processor's keys. And the Linotronic version of this em dash is available only to MS-DOS users who have version 3.1 of the PostScript driver; call Aldus for an update if you need it. PageMaker also allows you to type a command key sequence to obtain the em dash, and other symbols, from special character sets.