Christopher B. Browne's Home Page

5. An Opinionated Discussion About Word Processors

(Or: Do you want to process words? Don't you really want to process a document? )

I am not really thrilled with the term word processor, as it is not particularly descriptive of the sorts of things people actually want to do. Unlike the "good old days" when WordStar and Wang Word Processors were "king," these days, people don't process "words;" they want to build tables (that are not words), insert pictures (that are not words), include spreadsheets or graphs (that are not words). Even "back in the good 'ol days," people weren't really working with "words;" that is a task for a dictionary, thesaurus, or some other such "word" manipulation tool. It was always "documents" that people wanted.

Unfortunately, too often these days, people have so little grasp of the language that they are using that they cannot even spell the words or string them together in correct order.

The term that I favor over "word processing" is document processing, as it more correctly describes the thing that people are actually working with.

Some common varieties of documents include:

Documents might contain nested instances of other documents (e.g. a fax may be composed of a cover page that is attached to a letter and some other documents). One could develop a whole taxonomy to represent specializations of reports, where the following examples merely scratch the surface of the richness of representation that is possible:

Keeping purpose to this, these are all sorts of documents with which one might reasonably attach some sort of common structure, perhaps creating a "template" containing some combination of formatted text and graphics to allow individual documents to be written more quickly.

People tend to use word processors to "manage" many of these sorts of documents, generally making up uninsightful names on file systems that ultimately make finding old documents a big headache.

They would be far better off having some more formal document management system, as well as some sort of "template" to simplify the process of creating each sort of document.

Unfortunately, adding "structural" intelligence has the tendancy to make document processing systems somewhat more complex to use. Ensuring that users can handle the sophistication is not a trivial task. There is value to having the user interface discourage them from doing "wrong things;" if the interface does not also encourage them to do "right things," then users will get frustrated, leading to rejection of the tool. Thot and Amaya are good cases in point; while they may ensure that documents are nicely structured, but I always found that I was fighting against their structuring approach.

Equally importantly, "half-powerful" tools are all too common. The "GUIed" HTML editors that I have used generally do not handle HTML comments very well, either omitting them or otherwise changing their formatting. I use HTML comments as indicators for HTML reprocessing, and thus if those comments are "mangled" or omitted, my web pages are mangled as a direct result. Lyx, a LaTeX generator, is "afflicted" in the much same fashion. It uses a subset of LaTeX functionality; if you modify a Lyx file beyond that subset, Lyx can no longer be used to edit the file without "mangling" the results. Proposals to build improved configuration systems to assist with Linux system administration frequently suffer from much the same problem; if your X11 configuration makes use of tools like the M4 macro language, then it may prove impossible to construct standardized tools to manage the configuration.

OpenDoc provides still another view of this; it builds up documents using "object components." While mighty cool, this kind of architecture failed. I'd speculate this is because the intricate interfacing between different object types led to explosive complication in the software necessary to support it, which made it unmaintainable in the longer term.

In stark contrast, users like Microsoft Word, because it lets them do virtually anything anywhere at any time in the document. It may be unfortunate that it encourages them to use physical markup rather than structural markup, but they are nonetheless rarely frustrated. (At least, not until the writer gets the document nearly complete, and a "graphics" person finds it impossible make the sweeping revisions required to make it look attractive in the time needed.) The designers at Microsoft may produce some supremely awful products, but they are not dummies at producing things that provide "user satisfaction" by making it easy to make the computer do something that appears to be useful when the user clicks on things.

There is a huge number of projects listed to develop a "libre" word processor that runs under Linux. Unfortunately, most of these projects appear to be moribund, and none of them are really "complete." The Linux Word Processor Project seems a lot like The Great American Novel, something that lots of people get started, but are never able to complete. Everyone seems to get about half-done and then gives up on further development.

I would argue that this all points to the notion that constructing a really good WYSIWYG word processor may in fact be the most difficult programming task known to man. There is little doubt but that creating a spreadsheet package is enormously simpler; the use of a grid of fixed-width cells fundamentally simplifies the task as it tightly constrains the flow of data across the medium.

The problem with constructing a WYSIWYG document processing system is that it simultaneously combines many sorts of complexity all at once.

5.1. Low Level Arrangements

5.2. Paragraph Structuring

Then comes "paragraph structuring," where indentation both left and right, spacing, font selection, and line justification all vary based on the "paragraph type."

5.3. Page Structure

Different parts of a document will need different page formats:

5.4. Dynamic Modification

The various sets of "rules" build up an overall set of "document specifications" that represent a complex dynamic program. (See Dynamic Programming.)

The TeX system was designed to handle these sorts of systems with extreme precision, and does so quite well. Unfortunately for those that would like to see "visually dynamic" representations (such as WYSIWYG), the TeX system provides an relatively "static" representation. It really is "batch"-oriented.

TeX and LaTeX are designed to allow structural markup, which is not nicely compatible with the "physical" markup that WYSIWYG encourages, which begins to touch on the real complexity problem:

These remappings affect the presentation of text at varying "logical levels." Moreover, better word processors do provide some degree of structural markup (not unlike what LaTeX offers), which nicely multiplies the complexity.

By providing this sort of interface, it becomes necessary to simplify the way things are presented so that the results can be interactively recomputed "in a flash." Quality is lost at this point. Moreover, users are often not sure at a point in time what kind of change they really intend to make.

Should shifting the margins for the current paragraph affect other paragraphs? The answer depends on context:

The big question is, of course, which "document policy" is to be kept and which is to be ignored when making changes.

The first result of this ambiguity is that the user interface for this is highly complex to code. The programmer's job is made difficult. Which is unfortunate, but arguably not a critical problem. It is the programmer's "job" to provide a good program; the needs of the many (users) arguably outweighs the needs of the few (programmers).

The second, more problematic, result of the ambiguity is that it is difficult for the user to predict how the overall formatting of the document will be affected by any given modification.

Thirdly, typesetting that produces attractive documents uses a large variety of "rules" that together represent a complex set of tradeoffs with which the user may not be familiar. A user knowledgeable about typesetting may break the rules with intent to attain a particular result. More often, users don't know what they're doing, and would get better results if the computer enforced the rules on them.

Contact me at