October 23rd, 2006 • 9:52 pm
Well, I have to correct what I wrote earlier today about the useless “fix” for the problem with Postscript fonts and the non-breaking space in Word 2004.
It turns out that it was indeed the Microsoft Office 2004 Update 11.3.0, designed and blessed by Microsoft’s fine engineers, that did change the behaviour of Word 2004 with Postscript fonts and the non-breaking space.
How do I know? Because, as a more careful user than myself pointed out to me this evening, Microsoft itself says so in its own Read Me file for the 11.3.0 update:
3.2.2 Font does not change to Times New Roman after using a non-breaking space
This update fixes an issue that causes text typed after a non-breaking space to change unexpectedly to Times New Roman font.
Yup, they fixed it—and they are proud of it.
There is, of course, only one slight problem with this: The fix provided is frigging useless!
It only works properly when the non-breaking space is inserted manually by the user. Yet, as every French-speaking Word user knows, and as I clearly explained myself to the Microsoft engineers who had deigned to sort of feign interest in the problem earlier this year, Microsoft Word normally takes care of inserting the non-breaking spaces in French punctuation automatically, with its “smart punctuation” feature.
And guess what? The “fix” provided by Microsoft’s engineers does not work with the “smart punctuation” feature! It only works when the non-breaking space is inserted manually, which French-speaking Word users only have to do either if they’ve turned the smart punctuation feature of or if they are editing existing text and the smart punctuation feature is not smart enough to do it for them.
In other words, by default Word inserts the non-breaking spaces automatically, and they are still in Times New Roman when the underlying font is a Postscript font, which means that, for all intents and purposes, the bug is not fixed.
And here I was trying to kindly get the MacBU engineers off the hook by blaming Apple for the half-baked fix… When in fact the MacBU engineers in question deserve all the opprobium that can be heaped on their heads.
I mean, how stupid can you get? Do they even know how their own software works? Do they actually read with a minimum of care the feedback that we are hopelessly trying to provide to them? Quite evidently not.
And now they probably think that they have fixed the problem, and have promptly removed it from their “to-do” list, which probably means that it will not be fixed properly in Office 12 and we’ll have to wait another three years before anything is done about it.
This is beyond ridiculous. One finally manages to get the attention of a couple of MacBU engineers on a rather obvious bug that has been there for two years without them doing anything about it, one finally manages to convince them—almost by taking them by the hand through the whole thing from the very beginning—to do something about it—and they still manage to screw up the fix itself!
This is beyond belief.