All Posts for This Blog (newest first)
The RTF document format grew in parallel with Microsoft Word. Parsing and interpreting formatting controls when styles are mixed with direct formatting can be a challenge. Perhaps that’s why many RTF parsers ignore styles and their value as a structural device. RTF is a widely supported document encoding format which grew out of and closely paralleled the evolution of Microsoft Word. According to Wikipedia: Richard Brodie, Charles Simonyi, and David Luebbert, members of the Microsoft Word development team, developed the original RTF in the middle to late 1980s.
People talk about documents by saying things like: “this is a plain text document”, “this is an XML document”, “this is an HTML document”, “this is a Word document”, “this is a Markdown document”. These phrases describe the way the document has been serialised as a stream of bytes in a file — i.e. they describe the file format. But a document has more abstract qualities than just its file format.
Before going on to examine how a different kind of text preparation tool could make the structuring task faster and easier, lets take a closer look at this task of structuring a document. Consider the very common case where a designer is handed a word processor document to prepare for publication. Let’s assume that the “typographical cleanup” has been done and that structuring the document is the next task.
In this post I want to suggest that a publication designer needs a different kind of text preparation tool than the typical “word processor” used by authors. Old and New Ways In the past, the craftsman typesetter received a handwritten or typed manuscript from an author or editor and was able to exert complete control over the typesetting process — translating pencilled markup into a typeset text galley embodying the arcane rules of high quality typography.
Fredrik from Utrecht in the Netherlands wrote to me in 2010 about publishing workflows. His experiences are similar to mine, so I quote from his email and add a commentary. I had explained to Fredrik about my background in publishing and talked about the typical problems experienced with publishing workflows. Fredrik’s comments are shown indented below: My background is also in publishing, so I indeed know the problems you are talking about.
Sometime around May 2010 I was interviewed by British software developer “Scotty”, the genial host of the MDN Show. MDN stands for the Macintosh Developer Network and the MDN Show was a podcast about programming on the Macintosh. The show had originally started as “Late Night Cocoa” some years earlier, when each show consisted of an extended interview with one software developer. The MDN Show in contrast had more of a “magazine” format.
For many years I worked in publishing and have personally typeset, designed and supervised the production of what must amount to hundreds of books, journals and brochures using technologies beginning with manual pasteup right through to the latest version of InDesign and including markup-based systems like TEX. One goal of publication design is to help the reader understand the structure of the document they are reading. Designers use typographic and design conventions (e.
Having spent many years using computers to prepare publications, it became obvious that the widely used word processors were less than ideal tools for preparing text for publication. As I thought more about this, ideas for a new kind of structured document editing tool came together in my mind. This project is an attempt to embody those ideas in a piece of software. The Concept of the Structured Editor Text files received by print or web designers often need a lot of cleaning up.