A drawback to writing your own word-processor

So I wanted to write a word-processor whose native format was plaintext or close to it. This was to support version control, portability, and tool unification. I hacked something together in an evening and have used it for a couple of stories. To get a PDF you do this:
  1. Write the story in Textile. Eclipse has an almost nice WYSIWYG editor for this.
  2. Load the story into my Viewer, which is a simple Ajax application that renders textile, applies CSS and generally gets it ready for printing.
  3. Print to PDF
This is actually not as bad as it sounds, and I have to say it's really nice to format a story (or any printed document really) using CSS. It's also really nice to write a story using the same tools I use to code. Code folding and syntax-highlighting is useful in stories, too! (Would be nice to define a "Convert to first person" refactoring?)

The big drawback is that, after printing, it's almost impossible to integrate edits made in pen back into the plaintext. It's a drawback I just didn't expect, which makes it interesting! With an ordinary word-processor you have 1-1 page correspondence, and you locate the edit spatially. This is totally lost with my method, and it's a deal breaker.

The only way is to scan the text for the nearest heading and then for paragraph breaks and then keywords. It's slow and difficult.

Interestingly, this is also something of a problem with Google Docs, which also does not render page breaks.

One work-around is to render the textile text in the same shape as the printed page. I haven't tried this and I don't want to talk myself out of it as a solution, but it seems like this would be pretty difficult to do correctly. Another work-around would be to actually do the editing within the browser. Of course, there the problem is that I'm no longer using friendly tools.

For now the roll-your-own open technology wordprocessor for stories is on the backburner. But who knows? I might resurrect it.

No comments: