Markup or WYSIWYG, that is the question. I've done it both ways. In my academic life, I wrote extensively using markup languages, including runoff, Scribe, and LaTeX. The editing itself was done using Emacs (the One True Text Editor). I've also done a lot of writing using WYSIWYG systems, primarily FrameMaker. WYSIWYG is better.
It's better for two reasons, but before I get to those, I have to address the markup bigots who argue that WYSIWYG editing mixes structure identification (e.g., "this is a subsection") with presentation decisions (e.g., "subsections should be in 11 point bold Palatino and numbered n.m"), a situation sometimes derided as WYSIAYG ("What You See is All You've Got"). Sure, people can do this, but paragraph and character formats (as FrameMaker calls them) or styles (as Microsoft Word and OpenOffice Writer do) also make it possible to separate structure and presentation, and anybody writing something as long as a book will soon learn to do so. There's no dichotomy between WYSIWYG editing and separating structure and presentation.
I should also mention that I generally produce camera-ready copy for my books. That means I'm making most of the decisions about presentation myself: page layout, font choices, all that fun stuff. I've observed elsewhere that preparing camera-ready copy is probably not a good use of an author's time (scroll down to "Typeset"), but I have my reasons for doing it (or at least most of it), so ignoring the details of what things look like is not a practical option for me.
WYSIWYG authoring is better than markup-based authoring for two reasons. The first is latency in error detection. Suppose I want to specify that a paragraph is a second-level bullet point. With a WYSIWYG system, if I select the wrong paragraph or I don't specify a second-level bullet, I see the result of my mistake immediately, and I can correct it without further ado. With markup, I don't notice that I've done something wrong until I submit my document to the document formatting engine and look at its output. Call me a renegade, but I don't enjoy finding out several minutes after failing to close an italicized (er, excuse me, I mean emphasized) section of text that my entire document is now in italics. I'd rather see the problem the instant I specify that something is to be italicized/emphasized.
The second reason I prefer WYSIWYG editing is that what I see on my screen matches what I see on paper. This is important when editing. Having printed a section or chapter and annotated the hardcopy with changes to be made, if I need to reword a sentence at the end of page 2, I want to go to the end of page 2 on my screen and start editing. With WYSIWYG, I can. With markup, what I see in Emacs bears no resemblance to what I see on paper, so before I can do my editing, I have to search for a phrase in the text near where I want to edit, then map what I see on the screen to what I see on the paper. Only then can I start editing. It's primitive and a waste of my time.
When looking for authoring software, then, I really want a WYSIWYG system. Unfortunately, I'm not happy with my options. I run Windows (so sue me), so I need something that runs on that platform. I've written my books since 1992 using FrameMaker, and let me just say that I hate it. I don't really know Microsoft Word, but I've heard enough bad things about it to consider it a low-percentage option, and my limited experience with it reminds me of C++: you can do pretty much anything, but almost everything is complicated by the fact that features interact in ways that make sense only if you understand absolutely everything. I wanted to use OpenOffice Writer, but I wrote an article using it, and that experience demonstrated that Writer just isn't up to what I want to do. (Cross referencing was painful, and PDF output was essentially nondeterministic when the layout included floating display elements like figures, listings, and tables.)
I've recently been looking at WYSIWYG XML editors supporting DocBook, but since one of the advantages of DocBook is that it can be transformed for display on different output devices (something I definitely want), I began to realize that the meaning of WYSIWYG is less clear when you'll be "getting" different things for different output devices. Presumably this an issue familiar to web designers who (properly) employ "liquid layout," i.e., allow line breaks to be determined dynamically, because that means that the appearance of their web pages is affected by the width of the window in which it is displayed -- something over which they have no control.
I find myself seeking a WYSIWYG editing interface for a document that may be formatted for several different output devices with varying capabilities and characteristics (e.g., font selection, support for color, physical size, etc.). What do you think I should do?
Subscribe to:
Post Comments (Atom)
6 comments:
Perhaps one option to consider is a good WYSIWYG XHTML editor such as Adobe DreamWeaver, and create multiple stylesheets with different "media=" attributes -- one for web, one for print, one for cell phones, etc.
I'm not 100% certain how you'd get deterministically-formatted PDFs in this manner, but maybe someone else will chime in with a good approach for this aspect...
I guess something that supports both markup and WYSIWYG would be ideal. I say this because I too generally prefer WYSIWYG but then sometimes you just cant get what you want without resorting to markup.
Wiki (especically TWiki) supports both but then it would only be an online book.
It seems like you're on the right track looking at DocBook. I would suggest doing some initial attempts with the new version 3 of OpenOffice.org Writer too, since that gives you certain intangible benefits, along with the ability to switch platforms when someone does sue you for using Windows. (tongue-in-cheek) Of course, the article you read may have applied to version 3, in which case "never mind."
I think that a more important goal than selecting your most-perfect authoring tool is to set your own expectations. As you noted, the need to produce copy that is pleasing on platforms ranging from 32" WQXGA screens to the iPhone and Kindle, in formats spanning PDF, paper, HTML, EPUB, and Kindle-compatible Mobipocket, implies that you have to abandon the eight-and-a-half-by-eleven mental model. Winnow through your expectations for what it means to be WYSIWYG, and select the things that are A) truly important and B) common across all of these formats and platforms. The primary need, I think, is to make sure that graphical elements are located near to the associated paragraphs of text, and the secondary is to be sure that graphics are crisply legible on all of these platforms. After that comes rendering of italics, monospaced and bold text on platforms that support them, and finally structural formatting such as bullet points, titles and section headers. On minuscule screens, it is desirable to permit headers and titles to look more similar to the body text than they would in larger electronic or paper renderings. As an excellent example, try rendering a PDF in Adobe's Reader for Palm devices.
Your primary urge for WYSIWYG and PDF might be related to the editing task you describe. The common word-processing tools, whether OOo Writer, Symphony or MS Word, or something more publisher-oriented like Frame, should meet this need amply as long as you maintain your expectations limited in time. As in editing source-code, the differences between two files (printed and on-screen, for example) will be easily navigable as long as you work the changes starting at the end of the document and within a relatively short time of having printed the proof copies.
I've put nothing earth-shattering in the above notes, but I hope that the collection of thoughts and suggestions will prove useful. I'm certainly eager to see what you have to say on the subject of performance, as it's an issue that appeals to me as a programmer and perfectionist.
Fairly accurate. WYSIWYG makes sense when
1. You're going straight to camera ready copy.
2. You're only publishing in one medium.
I usually don't do my own camera ready copy, so even when I'm using Word/OpenOffice etc. there's no such thing as WYSIWYG. The publisher's going to completely reformat everything anyway.
I also find non-WYSIWYG-based approaches to be superior when I need to combine multiple files: text, code samples, images, and the like. If I can just write word sin a row, WYSIWYG makes somewhat more sense.
Part of the problem is that few word processors are really designed for professional publishing. Word and OpenOffice certainly aren't up to the task. Only FrameMaker ever really managed to combined the flow of a word processor with the accurate page layout needed for professional publishing.
Have you looked for a 'DocBook' plug-in? You mentioned that you use Windows. So, have you seen:
http://www.sydock.com/asp/docbook/
I have never used it, I'm simply suggesting taking a plug-in approach.
I understand why you want WYSIWYG, but I just don't know that it is ever going to work (even putting aside the point that you are trying to design something for which there is no unique WYG).
I was working today in a WYSIWYG math editor, and was trying to place some parentheses. I'd already learned (negative feedback - it works) that it was better not to open a paren, type the contents, and then close the paren. That confuses the s/w. Results are more reliable when you type the expression, select it, and then press the "put this all in parentheses" key.
But for the WYSIWYG to work, it's got to have some smarts: it has to know what you are doing - particularly, what kind of scope you intend.
And this program kept guessing wrong. Of course, I had parens at all because it was a long expression. Not the kind of thing one wants to type over. The kind of thing one wants to edit in place. It's just a parenthesis - what could go wrong? But the software kept guessing wrong at what I wanted. It was so insistent at guessing, and so consistent at erring, that I finally had to bite the bullet and type the damn expression in from scratch again (two or three times until I could figure out what order would not confuse it).
Had this been a nice markup language - like TeX, say - or had the option to reveal the markup behind the display, I could have easily (one imagines - hope springs eternal) tweaked things the way I wanted them.
I think you will be hard pressed to find a WYSIWYG program that will give both the power and the control to make sure that things work the way you want them.
Anyone who has ever dabbled in Word knows that it is very easy to strand little bits of formatting controls across the printed landscape, like little landmines, only waiting for an ill-considered edit to bring them to set them off.
If you want to take control of your document, dammit, take control.
If you want some bunch of programmers who have never thought much about what writing a book requires to control your text...well, just about any WYSIWYG system will do.
And then, of course, you've answered your own question: if you don't know what you expect to see - because the whole point is that you want to accommodate different kinds of viewers - how can you possibly expect a WYSIWYG system to work?
Post a Comment