One Tap or Two?

[This blog post is reconstructed from a draft dated April 5, 2006. The original post was lost.]

If you ever took a typing class, you were probably taught to press the space bar twice between sentences. Lately, more and more blogs have declared this to be wrong-headed advice. Today, they claim, with proportional fonts and improving electronic typography (even on computer screens), you should use just one space between sentences. But the debate rages on. So what’s a poor keyboardist to do?

If you’re a serious author, you should be writing rather than surfing, so I’ll give you an early out: prepare your manuscript whichever way your agent, editor, and publisher want. Period. Now close your browser and get back to work.

Still with me? Good. The rest of us will now debate this trivial point with a religious fervor that rivals operating system wars.

On a typewriter, or with a monospace font on a computer screen, there is only one type of a space: a simple gap the same width as any of the other characters in the font. If you need more space, you can line up several of these simple spaces. In fine typesetting, however, spaces are much more flexible. If you justify both margins of your text, spaces are stretched (and sometimes even squished) to make the lines come out to equal lengths. Printers have all sorts of spaces, from the interword space we all know and love, to em spaces and quad spaces and probably zillions of others. The sizes of these gaps are dictated by the font face and font size.

The debate, therefore, is not one-space-or-two. This oversimplification of the question is the root of much of the disagreement. Nobody thinks that, in a proportional font, intersentence spaces should be twice as wide as a regular space. We have to stop conflating these two ideas. First, should the spaces between sentences be any different than the ones between words? Second, how many times should you, as a keyboardist, hit the space bar between sentences?

Should there be a difference?

Donald Knuth, a professor of mathematics and computer science, pioneered fine electronic typesetting by developing TeX and Metafont, tools which many technical publications still use for producing high-quality documents. (I believe Metafont was the first application of scalable outline fonts.) If you know Knuth, you know he doesn’t do things halfway. From his writings on the subject, it seems he has studied the entire history of putting ink on paper.

According to Knuth’s design, whether and how much extra space goes between sentences should be determined by the font designer. Therefore, there is a distinction.

TeX’s model of a space is not just its natural size, but also how it can stretch or squish when it is being adjusted during justification. In TeX’s default mode with the Computer Modern fonts, spaces between sentences are fractionally wider than ones between words. The difference is so small, you can barely tell. When justifying the text, those intersentence spaces are stretchier than the interword ones. In fact, TeX also makes spaces after punctuation marks like commas, which don’t end sentences, stretch faster than interword spaces (though not as fast as intersentence spaces).

TeX also offers a mode, called French spacing, that lets you override the font designer by eliminating these spacing distinctions and makes all the spaces the same size and stretchiness.

I should let the typographers and font designers battle over whether it’s right to make a distinction, but I have my opinions.

Personally, I prefer to read material that adds a little extra space between sentences (and, no the open space above a period doesn’t do it for me). I’ve been noticing that fewer and fewer new books are typeset this way. I find myself stumbling and re-reading a lot more, especially in fiction with lots of dialogue. Although the extra space is a tiny, subtle cue, it’s something I notice. Please God, when e-books finally catch on, please give us a choice to read them in either mode.

Apparently I’m not the only one who stumbles without longer spaces between sentences. This comment on screenwriter John August’s blog points out that actors reading aloud stumble less when there’s extra space between sentences. This isn’t a totally fair comparison, because he’s talking about a typewritten (monospaced) script. Nevertheless, it supports the idea that the spacing between sentences should be distinct from the spacing between words to help the reader.

Another reason to distinguish is to eliminate ambiguity. These two lines have slightly different meanings:

"Run!" I gasped.

"Run!"  I gasped.

I’ve used a monospace font to make it clear. The first example is a single sentence (and a good example of bad dialogue). The second one is two distinct sentences (and avoids using a cheesy dialogue attribution). Yes, it’s contrived, but I stumble across a few of these in every novel I read. And even when the spacing isn’t the sole clue to the sentence boundaries, it can help the reader by being a redundant clue.

The font designers and typographers may now proceed to argue over “color” and “rivers” until their hearts burst. For the rest of us, it’s enough to know that at least some reliable sources do make a distinction between interword and intersentence spaces.

What should you type?

My keyboard, and I assume yours, has only one space bar, so how can we distinguish these spaces when we type?

Well, that all depends on which rendering method you’d like to use. And, as it turns out, most rendering methods suck.

If you’re typing plain text, in a monospace font, use two spaces between sentences. There seems to be little debate over that.

If you’re composing an email, be aware that the reader might see it as plain text, even if you try to format it with HTML or rich text. Reading incoming mail as plain text is an excellent defense against web beacons and browser exploits in all that spam that slips by the filters. If your text can’t make the point without the fancy formatting, then you should probably be spending more time on content.

If you’re writing for the Web in HTML or XML, it doesn’t matter how many spaces you type, because (with a few exceptions), it’s going to treat any number of consecutive spaces as a single space. That’s good news for those of you who have a hard time changing your typing habits, but it sucks for readers who want a little more room between sentences.

If you’re using TeX or LaTeX, it doesn’t matter how many spaces you type. No really. Go ahead, put 42 spaces between your next two sentences. Trust me. It’ll be fine. TeX can usually figure out all by itself which spaces are between sentences. Unfortunately, the algorithm isn’t perfect, so occasionally you do have to give it a hint, especially in dialogue and after certain kinds of abbreviations.

I’m not sure about troff.

I had a colleague

who would write

in short phrases

like this.

He found it


to edit and proofread.

troff then turned his text into normal type. Nobody else ever knew how strange his source files were.

Let’s see. What else. Oh yeah, Word. If you write in Word, I’m sorry. Word is schizophrenic when it comes to how many spaces you type. On the one hand, since it’s a WYSIWYG editor (WYSIWYG is the wrong paradigm for composing text), every space you type becomes a space on the page. If you type two spaces between sentences, you’ll end up with intersentence spaces that are twice as wide as a regular space. And, if you justify the text, that gap will stretch twice as fast. We all agreed at the beginning that this is bad. And it’s the primary reason why so many people have oversimplified the issue in their blog and described the two-space tap as “100% wrong.” On the other hand, those of you brave enough to leave Word’s grammar checker turned on may have noticed that the grammar checker screws up less often if you put two spaces between sentences. This, in and of itself, isn’t a strong argument for using two spaces.

Still, I cringe every time I see a blog recommending that people use a global search and replace to change all of the space pairs into single spaces. It just doesn’t seem right to throw that information away. What we need is a better rendering method. One that lets writers type however they like and lets readers choose how they want the text displayed.

For the record, I’m an unrepentant double-tapper.

Servo Animation

One of the (far too many) projects I’ve been working on is a video game. You might call it a sports simulations—then again, you might not, depending on your idea of what constitutes a sport. Nevertheless, it involves players waving sticks at balls, trying to get the balls to go in the right direction.


For the core of the game engine, I’ve built a physics simulator. Back in college, I had a tenuous grasp on Newtonian physics, which came in handy as I was earning my degree in physics. As with many things, you have to use it or lose it, and I haven’t exercised my knowledge of physics much since graduating. So, in addition to the figuring out how to translate conservation of energy into floating point math, I had to relearn some physics and, especially, some calculus. If you find yourself in the same boat, I recommend this series of articles from Chris Hecker as a warm-up:

Those will help you (re-)learn the physics and math necessary to make a nice 2D simulator (think Crayon Physics). With those as inspiration, these heavy-duty tutorials from David Baraff will help you build a nearly-complete 3D simulator:

My simulator is built almost directly from the latter two references. While these are hard-core articles, there is a lot more to this field. Fortunately for me, this was plenty to do the basic bouncing balls simulation that are necessary for my game.

At least, I thought it was. I have the balls bouncing, rolling, and smacking into each other, all under the control of the physical simulation. What I need now is to blend the simulation with canned animations and with input from the user. The question is, how do I handle the interaction of the animation-controlled objects with the simulation-controlled ones?

Consider a canned animation of a 3D character swinging a bat. There’s a ball hurtling toward the player’s avatar. The player presses a button to start the animation. Frame by frame, the bat’s position is updated. If the bat hits the ball, an impulse needs to be imparted to the ball. But since the swing is just a series of positions, we don’t have all the physical values necessary to compute an accurate force to apply to the ball. You could probably guesstimate the change in momentum and send the ball flying off in a plausible way, but what about the bat? If I continue with the animation of the player’s follow-through, you won’t see any recoil on the bat itself. The bat will continue on its trajectory as though the player had missed the ball.

This is a quandary I’ve been pondering off-and-on for a while. But after the MazeBot project, the answer came to me: servo control.


MazeBot has a compass sensor that gives its orientation in degrees with respect to magnetic north. At any point in time, MazeBot’s software has a desired orientation. The difference between the desired orientation and the measured orientation is the error. The error is used to compute how much power to apply to the left and right motors in order to turn the robot back to the desired heading. This is repeated many times per second in order to keep the robot on track. This is called servo control.

Now here’s the neat part. To execute a turn, the software “animates” the desired heading from its original value to the desired value. For example, if the robot is at heading 18 and it wants to turn 90 degrees, the software changes the desired heading to 19, then to 20, then 21, and so on, until it reaches 108. That’s it. It doesn’t directly issue any commands to the motors.

In the background, the servo controller is always running, trying its darndest to keep the robot aligned to the desired heading—even when the desired heading is a moving target. Thus the robot turns. How closely it follows the animated path depends on how well-tuned the servo controller is and how responsive the mechanism is.

Servo Animation

Suppose we applied the same idea to the animation of the bat. The bat could be just another object that the physics simulator controls. Rather than telling us where the bat is, the animation path tells us where we want the bat to be. We feed that desired position into a servo controller just like the desired heading is given to MazeBot’s servo controller. The servo controller returns the force (and torque) that should be applied to the bat to keep it on the animation path.

Now that the bat is a first-class citizen of the simulation, we have all the physical parameters we need to resolve any ball-bat collisions. The ball experiences a change in momentum and heads away to the outfield. The bat will also experience a recoil impulse causing it to momentarily fall behind the animation path. The servo controller will increase the forces to try to get the bat back on track, resulting in a swing that—while animation-driven—still responds in a realistically different way than if there had been no collision.

I haven’t tried this out yet. Given my project backlog, it might be a while, but I wanted to write up this idea while it was still fresh in my head. What do you think? Will it work?