What You See Is All You Get

I wrote this post after spending a couple of very frustrating hours sorting out corruption issues in a Microsoft Word document.

WYSIWYG ("What You See Is What You Get") word processors, which show you an accurate screen-based simulation of exactly what you'll see on the printed page, have ruled the roost since the advent of the Macintosh user interface and the ascendancy of its vastly more popular copycat edition, Microsoft Windows.

The most popular WYSIWYG word processor on the market today is Microsoft Word. Word is absolutely great for casual users but absolute hell on professional writers.

(Word is designed for people who don't know much about computers, and makes it easy for them to write short, simple documents like letters and brief reports. Ask any writer who works with complex documents about their experiences using Word, and you'll hear war stories, I guarantee it. Formatting nightmares. Corrupted documents and style sheets. I could go on. Oh man, could I ever go on.)

WYSIWYG has not always been so dominant. And for some of us, it still isn't: technical and academic writers have very different needs from casual word processing users. Tech writers regularly produce long documents (with complex structures and lots of graphics) on the job. And so even today, in the WYSIWYG era, many writers who work with long, complex documents prefer to use markup-language based systems, which completely separate content from formatting.

HTML, the basic markup language of the Web, is an example of a markup language that most people (who would hang out at this blog) are at least a little familiar with.

The advantages of a markup language are many, but chief among them: you can take the same source document and spit it out in a bunch of different formats without altering the source.

And mysterious, unexplainable problems that crop up in (say) Word documents just don't occur.

Among commercial products these days, the best examples of markup language-based publishing systems would be Adobe FrameMaker 8 and MadCap Flare. Both of these systems use XML. (There are many, many free, open-source implementations of XML, but these products are more like Erector sets than authoring and publishing systems; you have to figure out and customize a great deal of the workflow yourself.)

I use FrameMaker, and I'm evaluating Flare.

But as the saying goes, you never forget your first.

Let me, at this point, wax nostalgic for a moment about Sprint.

No, no, not the phone company - Borland Sprint, the best PC-based word processor it has ever been my pleasure to use.

Sprint, based on an award-winning early markup language called Scribe, was so far ahead of its time that it's not funny.

Unfortunately, it arrived on the US market just as the Mac and then Windows were taking off like rockets, and WYSIWYG, that pixel-painted hussy, led the unwashed masses down the garden path with its fancy interface and seductive graphics. :-)

But for one brief shining moment - ok, a couple of years - I got to produce documents using the nicest PC-based system a professional writer could hope for.

The Wikipedia article on Sprint lists some of the product's features - and they do not exaggerate, not one little bit:

Crash-proof: Sprint [had] incremental back-up, with the swap file updated every 3 seconds, enabling full recovery from crashes. At trade shows, demos were made with one person pulling out the power cord, and the typist resuming work as soon as the machine restarted. Swap files could also be saved separately and transferred between machines.

Spell-as-you-type: With this feature, Sprint could beep at you in real time when detecting a typo. (MS-Word needed almost ten years to have the red snakes under the suspect words.)

Multilingual editing: Sprint included dictionary switching, support for hyphenation, and spelling and thesaurus dictionaries that have yet to be matched by the competitors.

Separate formatter and programmable editor: These have been very useful features for corporate environments aiming at standardizing documents or building "boilerplate" contracts. In France, for example, sophisticated applications were built for Banques Populaires (loan contracts) or Conseil d'Etat, while some local government agencies created specific applications for tenders and contracts.

Powerful programming language: Programming in Sprint is done with the internal language of the word processor - a language which is very much like C.

Programmers have the ability to "get under the hood" and to add modifications and extensions to an extent not possible with other word processors. Once written, Sprint programs are compiled into the interface, and run at full speed.

Interface switching: Modifications and extensions to Sprint can be saved into separate interfaces which can be easily and quickly switched. This is very useful for people working in different languages, as the keys can be mapped to the accents and characters of each language, depending on the interface.

File handling: Users can work in up to 24 files at once.

Handling large documents: Sprint has the ability to publish very large documents (hundreds of pages) with strict formatting consistency and automatic table of contents, index generation, tables of figures, and tables of authorities. These features made Sprint a leader in the production of technical documents - and Borland itself did all its manuals on Sprint, for years.

PostScript capabilities: Sprint could print in-line EPS images with dimensioning, and also had the ability to add in-line PostScript procedures. This made the product rather popular in the printing industry. For example, making a 200 page novel fit into 192 pages was simply a matter of changing the point size from 11 to 10.56. Sprint could size by 0.04 increment and scale the line spacing and kerning accordingly. (The 192 pages size is important in the printing industry, where the number of pages often has to be dividable by 32. A 200-pages book would have to be printed using 224 pages, the extra 24 pages being empty.)

Not only was it a superior system for its time, you could still do useful, professional work with it today... since you could output to PostScript, a PDF is only a step away.

If only I could get my hands on a copy.

Well, would you look at that.