A Comparison of Word Processing vs Desktop PublishingConsidering today’s trend toward downsizing, streamlining, and cost cutting, companies are looking to become more competitive. Often they choose is changing to less expensive alternatives to the tools they are currently using, or not upgrading to more costly tools. One of the tools frequently targeted is the desktop publishing package. Many companies decide to stop using or not purchase packages like Corel Ventura Publisher, choosing instead to use Microsoft Word to produce their documents. The rationalization often used is that Word is cheaper both in dollars and in training time, as the company’s staff is already familiar with using Word. Unfortunately, that savings is illusory, since Word and Ventura approach layout in fundamentally different ways. Word addresses documents, while Ventura looks at publications. Word places elements in paragraphs; Ventura uses frames. Text formatting is handled in Word using templates, but Ventura applies style sheets. Finally, Word copies every element required by a document into the document file, whereas Ventura imports items into a publication by reference. Although Word does contain desktop publishing features, attempting to use it for a purpose that its design does not support gracefully saves neither money nor training time. Using it as a desktop publishing package is roughly like insisting that someone use a standard-head screwdriver to turn a Phillips-head screw, simply because you already have a standard screwdriver. It can be done but at a greater cost in time and effort than is really necessary. Looking at the big picture, investing in the right tool for the job up front is much more cost-effective in the long run. The bargain of the century may turn out to be more expensive than it seems. Who We AreManual Labour is a full-service technical documentation firm. We specialize in producing paper and online documents aimed at users who are competent or even expert in their own fields, but lack familiarity or comfort with using computers. Our clients hire us to create user guide, tutorials, online help, and other information products to explain their software development efforts to these users. Because we are a full-service firm, able to take a product library from concept to completion without our clients having to take more than an informational role, we are generally able to use whichever tool we feel is best suited to the job. More often than not, the tool we prefer for layout and production tasks is Corel Ventura 5.0 [Author's Note: Corel Ventura is no longer available; we now use FrameMaker 7.1]. Occasionally, however, we work with clients who are purchasing source documents, as well as final output. These clients (who rarely have in-house document production teams) require us to use MS Word for both initial text generation and final document layout and production. Thus, we are in a unique position to assess the strengths and weaknesses of each for the same tasks. While we do not fault these clients for their choice (since, for them, it’s not really a choice at all), we strongly recommend any publication team give serious consideration to the points we raise in this article. Documents vs. PublicationsA document is a discrete Word file that contains text, graphics, and formatting information. Word always thinks in terms of documents, whether those documents are combined to create a book or not. In fact, the book creation feature is even called “Master Document.” In and of itself, this is not a bad way to view files; in fact, it is particularly suited to the text-intensive world of word processing. There, the individuals working with files may not know document production extensively, or at all. Their training points to thinking of files as documents rather than pieces of a book. Their primary output usually consists of letters, briefs, case histories, or other documents that do not often require extensive graphic placement or concatenation into a larger whole. However, when you want to combine these documents into a larger whole, their very independence can get in the way. Since the files are meant to be stand-alone, they include everything you need to print the document—text, graphics, formatting information—right there in the file. This can result in awkwardly large files (see “Copying vs. Importing Elements” later in this article) which slow your desktop computer down, at the very least. If you consider the person who has to work within such a system, you can see that he or she will always be struggling against this framework; always trying to turn that screw with the wrong driver. A publication, on the other hand, is a set of linked Ventura chapters that combine to form a published volume. Ventura always thinks in terms of publications; you cannot open a file in Ventura without going through a publication to get there. If you are planning to create output that incorporates a number of chapters, this is the most effective way to regard the files: as part of a larger whole. Ventura requires you to think in terms of the entire publication not just a single chapter. From a training perspective, this focus means that the tool used supports the concept of the item being created. The Philips screwdriver fits neatly into the screw and turns without unnecessary effort. Paragraph Placement vs. Frame PlacementParagraph placement means that any item you want to include on a page appears in a paragraph. Word uses this to identify and track page elements. Even Word’s frames contain a paragraph, and their default location is relative to a paragraph. Again, this is not inherently bad but it is limiting. In Word, because the progression of paragraphs within a document tend to be linear, it’s hard to get them to line up vertically with each other (outside of a table, which has its own overhead considerations). This does not matter as much if your document is primarily text but if you have graphics that need to appear next to one another, the process is difficult and frustrating. Frame placement means that any element’s location on a page is determined by a container, a frame, that holds the information at a set of precisely determined physical coordinates. Ventura uses this placement method to identify and track page elements. Each chapter contains a base frame that identifies the placement of the primary elements (usually text) and as many subsidiary frames as necessary to hold all additional objects. You can attach a frame to a paragraph, but that paragraph exists within a frame. At all times, any page element in Ventura knows its precise location in relationship to its frame rather than a paragraph. Since frames are placed using physical coordinates, rather than by their position relative to items placed earlier or later in the document, they provide a much more flexible way to store page elements. Templates vs. Style SheetsA template is a collection of formatting commands applied to a document. The commands themselves are embedded in the document (albeit invisibly to the user), and tend to be document-oriented (if you want a change to be reflected across a set of documents, you have additional work to do). Word uses templates. Like the other examples we’ve cited, this is not necessarily a bad way to do things, but it can create an enormous amount of overhead in terms of creating a consistent look and feel to a document. Since a template is intended to be applied to a document, then adjusted as necessary, it really only serves as a jumping-off point for document formatting. Styles in a template are almost more of a suggestion than a command. Once a document based on a template is saved, the link between it and the original template is severed, unless you reapply the template. A style sheet is also a collection of formatting commands. Unlike a template, however, these commands are part of a separate file (often invisible to the user), not part of the chapter text, and tend to be publication-oriented (if you want a change to be reflected across a set of chapters, you make it once). Ventura uses style sheets. One of the major advantages to style sheets is their portability. Every chapter in a publication refers to the style sheet by means of “tags” (the only part of the style sheet that is embedded in the text itself). If you want to apply a completely different set of formatting commands, simply attach a different style sheet—as long as the names of the styles are the same, the tags in the text will match up with a style name in the style sheet. That style’s formatting will then be applied. Since a style sheet is essentially applied to an element of a publication each time the element is opened, the style sheet enforces consistent formatting, with the most recent definition of each style. The text and the style sheet are always tightly linked. Copying vs. Importing ElementsOne of the ways to get information (whether it is textual or graphic) into a document is to copy it into the document. This ensures that the information is always present when the document is opened. The downside is twofold:
Since Word copies all information (unless you take steps to provide otherwise), files grow to unwieldy sizes quickly. A moderately-size chapter (for example, of about 25 pages) can grow to consume almost 3 MB of hard disk space if you include graphics. The overall disk space required by the project is greater as well, since each graphic element is stored twice: once as an original art file and once as its embedded counterpart within the Word document. These documents are also more subject to catastrophic loss. If a document file becomes corrupted, you’d have to rework your text and recopy your graphics. Another way to get information into a publication is to import it by reference into the publication. This places a marker that tells Ventura where to find the text or graphic element. The downside is that that text or graphic element needs to retain the same name and reside in the same directory throughout the life of the publication. Everyone who works on the project needs to have rights to this area. The benefit is that each file size is significantly smaller. The total amount of disk space taken up by the project is also smaller since each element appears in the directory only once: the original file. Publications containing elements imported by reference are easier to repair than documents containing copied elements. If a chapter or publication file become corrupted, all you have to do is re-import the elements. If one of the elements is corrupted, it’s more likely to be corrupted only from Ventura’s point of view; you can frequently open the text or graphic in a different application and repair it. Word vs. Ventura in ActionThe concepts we discuss in this article were discovered over the course of two projects. The Word project was a tutorial manual for an engineering document retrieval system. There were three categories of user (each building on the tools available to the previous category), so we divided the manual into three sections, each with between two and five chapters. The chapter’s pages were numbered consecutively. We found that we had great difficulty treating these files as a “book,” given Word’s emphasis on individual documents. We had to enter a starting page number for each section manually as we could not rely on the Master Document feature to do it for us. This meant that any edit that changed pagination required us to open and edit every chapter that appeared subsequent to the edited chapter. The document’s layout required side headings. Since Word is paragraph-based and does not easily allow for paragraphs to appear side-by-side, creating the side headings involved including a frame in a style tag as well as the other formatting characteristics. Any graphics placed in the wide margin also had to appear in a frame, which was automatically attached to a paragraph on the page causing these graphics to move around with the paragraph—which was not always what we wanted. Word template-based styles caused other difficulties. To have a style change reflect across several existing documents, we needed to adjust the style in one document (making sure to check an almost invisible check box on the Modify Style dialog box), then open all the other documents using the template and reapply it (making sure to check an almost invisible check box on the Templates and Add-Ins dialog box). We used a number of screen shots throughout the book, which caused a couple of problems. Any time the screen changed, we had to re-shoot it and copy it into Word, Also, several of the chapters had to be split in two to avoid unnecessarily large files. The average chapter size was 1.8MB while the average page length per chapter was 17 pages. The total directory structure for this project contained over 20MB worth of files. The project took us approximately two weeks to design and layout (not including writing time). The Ventura project was a user guide for a proposal pricing system. There was a single category of user but the subject matter divided into several chapters. The chapters were numbered consecutively. We found that we had no difficulty treating these chapters as a “book” since Ventura’s publication structure reinforced this identification each time we worked on it. Instead of having to enter a page number manually for each chapter, we simply had to make sure each chapter ended on an even page (occasionally this required us to insert a blank page to form the verso). This document’s layout also required side headings. Since Ventura is not paragraph- based in the same way that Word is, a simple style setting allowed us to set two paragraphs starting on the same line; one in the margin, and one in the body. Any graphics placed in the margin also required a frame—but so did any other graphic. It was up to us to determine whether and how those frames should be anchored to a paragraph. Ventura’s style sheet-based styles made global formatting changes simple. All we had to do was make the desired change in the tag settings dialog box or using the Tagged Text tool and they were reflected automatically across the publication. No further effort was required. We used a number of screen shots in the user guide as well but they caused no extra difficulty in Ventura. We simply created the frame, anchored it where necessary, and imported the graphic. If we updated the graphic, the updated version appeared automatically in our chapters. The chapter size changed only marginally, as the graphic was added via a reference rather than copied in. The average chapter size was 32KB and the average text file length was 65KB (we used Rich Text Format to store the text), while the average page length per chapter was 17 (about the same as in the Word project). The total directory structure for this project was about 20MB (the same size as the Word project), but the document included about 50% more screen shots, many of which were full-page scanned reports, which increased the total size significantly. The project took us about three days to design and lay out (not including writing time). ConclusionBased on our experience, if you are looking for the most efficient tool to lay out a document, choose a page layout application. Although Word contains many publishing features, the overhead encountered in trying to make a word processor perform layout tasks adds too much time, disk space, and aggravation to a project—it’s just not the “bargain” it seems to be. About the Authors…Bonni Graham is the owner of Manual Labour, a documentation business with such clients as Hewlett- Packard, Xerox Document Sciences Company, and Arco. Don Rasky is a technical writer specializing in vertical market software documentation for Manual Labour. Inez Kirby is a staff writer and quality assurance and process professional at Manual Labour. Bonni can be reached at bgraham@ManualLabour.com.
|
Send mail to Webmaster
with questions or comments about this web site.
|