The current post follows upon its predecessor, which halts with an example of how a glyph representing something like its ideal antecedent doesn’t really suffice.
The most recent “something like” problem involves character spacing. As I’ve noted, Georgia does not include en- and em-spaces, respectively designated   and   in Unicode. Creating an image to substitute for a characterlike thing (I hesitate to say “entity”) means failing to take proper advantage of how browsers handle characters, spaces, and images. Browsers and current word processors know that they should remember a space at the end of a rendered line but, when full justification is applied (flush left/right), that they should eat the space—conceal its existence temporarily. If the page is redrawn at a different width—for example, a user resizes the browser window—and the space no longer occurs at the end of a line, then it’ll reappear.
A small inline image isn’t treated the same way. Ordinarily, there’s no call to eat EOL images! Our problematic scenario looks like this, where the underscore marks an invariant space:
sentence irregularly punctuated—_The town
Now, the invariant space should not be non-breaking; it’s fine for a line to wrap between the em-dash and “The”. When the characters above are on one line together, however, the position marked by the underscore should be the same width regardless of autospacing imposed by full justification. An en-space is the correct width for the invariant space, but under our current plan to use Georgia + little inline images, we’d have an image there. No browser will automatically and invariably attach an image to the glyph that precedes it. For our purposes, it’s unacceptable for the en-sized image to wrap to the left edge of the next line.
Georgia does include the non-breaking space (HTML , Unicode  ), or we’d be redoing the font-choice discussion from scratch. The general nbsp issue is a nail/horseshoe/kingdom problem. A single-glyph ellipsis exists (…); it looks strange when capped by a full stop, as WordPress’s auto-substitution should show in this very sentence…. Since an ellipsis broken across two lines (thanks, line wrap!) would look dumb and obstruct reading, we’ve interspersed the dots of an ellipsis with nbsp. It’s not pseudokerned correctly, then, but it lets us have three- and four-dot leaders that match each other.
Typing can be good for thought: rattling out the two grafs above has let me solve the invariant-space problem. What we’ll do is set up an invariant space followed by a regular keyboard space:
sentence irregularly punctuated—  The town
to be rendered
sentence irregularly punctuated— The town
The resulting gap between the em-dash and “The” is basically em-width, which is too large. It’ll behave, though!
Yes, something like five users will notice that we’ve set up this particular issue properly. So?
I’m reminded of Greg Crane’s keynote, which he titled “Intellectual Life in the Age of Google,” and the trained-reader versus popularity-contest discussion it provoked. Till eyestrain fells me, I’m still on Team Precision, despite my vague sympathies for Team Bulk Access, because I’m more interested in mounting something that’s correct the first time around than in having readers offer incomplete fixes.