≡ Menu

Em spaces vs. En spaces revisited

I’ve always considered myself a sloppy writer (case in point: this weblog!). I haven’t really worried about stylistic/punctuation/grammatical consistency until near the end of a job. Then I go check everything once (maybe a global search and replace), and hopefully solve the problems.

However, I just realized that in some of my more important projects, my use of m-dashes and n-dashes are a real mess. Most of the time, rather than hardcoding mdashes, I’ve just used double hyphen marks (which is a definite no-no in publishing). I knew that when I did that. But I frequently experienced encoding problems with my text editors (or rather when I switched applications or exported content into another application). MS Word was notoriously bad with its “smart quotes” and I think it had the same problem with mdashes as well.

Frequently the destination was an html page, so I would cut and paste my text into some kind of html editor. Either I would manually put in the </p> <p> tags or I would run some command to replace the New Paragraph indicator with a <p> tag.

In the last few years, to eliminate precisely these kinds of problems, I’ve been using Notetab Pro (for simple text editing) and Oxygen XML editor (which handles encoding in a fairly transparent way). Notetab Pro has a nice Txt-to-HTML feature as well as various other text processing functions that I love.

So normally my workflow is to create the text document in Notetab Pro, print out drafts and reedit until I’m ready to start using HTML. Run the txt-to-html macro (maybe running some extra global replace commands to remove <br /> commands or space break commands. Then, in Oxygen, everything usually plays nice. Once things are in the XML editor, I print the rendered text from the browser window. It’s kind of a bummer to do it that way, but it works.

But then there is that pesky problem of mdashes. Idiotically, neither Notetab Pro nor Oxygen have an easily accessible mdash button, so I end up manually typing it. Also, I usually end up wanting to type in <em>, <strong> and — when I’m typing drafts (not in the hmtl editor). Unfortunately, that defeats my text to html conversion program, which escapes anything that looks like raw code.

So here’s my stopgap solution. Rather than type “” into the text editor, I type simply “mdash” (so I can globally replace it after I run my html conversion program). The problem is that mdash runs into the words it is sandwiched between. There is some controversy about whether mdashes or ndashes are better for conveying pauses or breaks in sentences. That is related to the problem of whether mdashes should be separated by spaces or should be sandwiched without spaces.

I have no opinion either way. It seems to make more sense that mdashes should be separated by spaces (though that opinion is definitely in the minority). But it raises another question. It’s nearly impossible to proof drafts where the coded mdash entity runs continuously with the surrounding words. On the other hand, using instead does assume surrounding spaces; so I can view/edit/proofread those drafts fairly easily.

While researching this, I noticed Richard Rutter’s Elements of Typographic Style as applied to the web. It is based on Robert Bringhurst’s famous book with almost the same name. Rutter’s website tries to apply Bringhursts principles using CSS. Nifty.

Also, much as I loathe Microsoft, I recently installed MS Office (for work) and have been enjoying its grammar/spelling functions. There are quite a few false positives, but it’s now a mandatory step for me to paste my html page from the browser and see the suggestions that MS Offices offers. It can be right a lot of times. Now, if only I’d do that with my blogposts.

Recently I’ve become a cheerleader for Google Docs, which is a fantastic editing environment. It also lets you output into PDF, HTML, DOC (not to mention your blog!). In other words, it is like the holy grail, with versioning and collaboration.  Saving things on google means that you can go back and compare versions with previous ones, eliminating the possibility of accidental deletion. The two weak spots are offline mode (and autosave) and grammar-checking functions. I don’t know if I can feel safe working on a document for two hours and then finding out that I’ve been offline for an hour and a half (and unable to save!). Also, MS grammar feature is light years ahead of google docs.

Actually, as an experiment, I think my next post will be created with Google Docs.

{ 0 comments… add one }

Leave a Comment

Next post:

Previous post: