Have you tried using U+00A0 NO-BREAK SPACE instead of the regular space?
EDIT
I often have to use the various Unicode spaces on StackExchange to get things to behave properly. For example, here are all the code points that Unicode considers whitespace:
U+0009 CHARACTER TABULATION
U+000A LINE FEED (LF)
U+000B LINE TABULATION
U+000C FORM FEED (FF)
U+000D CARRIAGE RETURN (CR)
U+0020 SPACE
U+0085 NEXT LINE (NEL)
U+00A0 NO-BREAK SPACE
U+1680 OGHAM SPACE MARK
U+180E MONGOLIAN VOWEL SEPARATOR
U+2000 EN QUAD
U+2001 EM QUAD
U+2002 EN SPACE
U+2003 EM SPACE
U+2004 THREE-PER-EM SPACE
U+2005 FOUR-PER-EM SPACE
U+2006 SIX-PER-EM SPACE
U+2007 FIGURE SPACE
U+2008 PUNCTUATION SPACE
U+2009 THIN SPACE
U+200A HAIR SPACE
U+2028 LINE SEPARATOR
U+2029 PARAGRAPH SEPARATOR
U+202F NARROW NO-BREAK SPACE
U+205F MEDIUM MATHEMATICAL SPACE
U+3000 IDEOGRAPHIC SPACE
Some of those are more useful than others. You can even use these to control kerning, when a glyph collides with another and needs to be spaced away from it. This wouldn’t normally happen in real typesetting, but browser tech is super primitive. For example, these all suck in unkerned Georgia roman — (jif) f’ f” f] — and are even worse in italic — (jif) f’ f” f] — see how bad that looks?
You can fix those with one of the Unicode thin-ish spaces. So you could for example write ( jif ) using a HAIR SPACE or ( jif ) using a THIN SPACE.
Primitive, but good to know, especially since the same trick will fix your problem, too, which is a much more frequent one than worrying about kerning collisions. Remember there are zero-width and no-breaking spaces too. Sometimes the four joiners and non-joiners come in handy, too, to make it behave the way you want it to.
For the screwups involving fi and such, it’s best to just replace it with compatibility ligature, U+FB01 fi. Yes, this messes up searches, but they should be being run with Unicode casefolding. Under Unicode, the two-character version and the ligature have the same casefold, so would both match. The core StackExchange code isn’t Unicode-savvy though, and doesn’t bother/manage/know to do casefolding correctly. Oh well.
But if they did, then ‘FINE’, ‘fine’, and ‘fine’ would all match case-insensitively, but because StackExchange doesn’t use Unicode rules, this needelessly fails.
Someday maybe they’ll fix the bug to use Unicode rules. Hope springs eternal. They probably should be using NFKD searches, too, but that’s a whole ’nother story. It’s a great way to improve your recall at the cost of some so-small-as-to-be-meaningless amount of precision. That’s what Adobe does, for example.
lastword ?
i.e. it gets auto corrected tolastword?
. I don't think that is correct in all cases - my desired title is an example.