Word 2004: Non-breaking space with Postscript font causes Word to revert to Times New Roman
Posted by Pierre Igot in: MacintoshSeptember 3rd, 2004 • 3:44 am
This one is for the Betalogue reader formerly employed by Microsoft who argued, the other day, that Microsoft did have a devoted group of staff members testing Word to make sure it worked properly with different languages and not just in English.
As I’ve indicated on several occasions, the non-breaking space character (option-Space in Word) is an essential character in French punctuation. You would think, therefore, that whoever at Microsoft tested Word 2004 for the Mac to make sure it worked well in French would have identified the most obvious bugs and got them fixed.
Think again. In Word 2004, if you are typing French text using a Postscript Level 1 font (any font from Adobe, for example), as soon as you type a non-breaking space, Word… changes the font to Times New Roman (a Microsoft-provided TrueType font, of course).
Can you believe this? Can you believe that no one at Microsoft noticed this before releasing Word 2004? It’s a huge bug for French writers. And of course it’s going to take several more months before Microsoft finally releases a maintenance update for Word 2004 that fixes the bug.
The lesson here is pretty simple: Do not use Postscript fonts with Word. Stick to the TrueType fonts provided by Microsoft. Do not use Word for any page-layout task. Use it to type text, and then place the text in a decent page layout application such as InDesign and use Postscript fonts to your heart’s content.
Unfortunately, not everyone has access to InDesign and not everyone can afford to incorporate it into their workflow.
But really, the bottom-line is that every new release by Microsoft comes with a truckload of unacceptable bugs that have to be endured for months before Microsoft fixes them. And the fact that these bugs stay undetected is a clear indication that Microsoft’s testing procedures are woefully inadequate. If I were a French-speaking beta tester for the MacBU, I’d be ashamed.
December 1st, 2004 at Dec 01, 04 | 10:30 am
By the way, if you remove/uninstall the TrueType version of Times New Roman, upon receiving the option-space keystroke Word 2004 switches to the New York font. (For this experiment I removed Times New Roman and installed the Adobe-supplied PostScript version of Times New Roman (which has the PSMT suffix, which stands for PostScript Monotype, I guess. Times New Roman PSMT comes with FrameMaker and is the preferred font for cross-platform FrameMaker work, I think.)
Word 2004 is an interesting program. :-) Now that Endnote 8 is available, I can finally use it for my work (or perhaps I should say that now I can be used by Word 2004).
I’m looking forward to the SP2 version.
December 2nd, 2004 at Dec 02, 04 | 1:06 am
Yes, I noticed that too… There is simply no way to work around that bug.
Personally, I am not getting too excited about SP2 — if it ever arrives. If SP1 is any indication, very little will be fixed. Can Microsoft afford not to fix such obvious, blatant bugs? Based on SP1, they can… So why would they fix them in SP2? They obviously have different priorities than the rest of us.
December 2nd, 2004 at Dec 02, 04 | 9:19 am
If the New York font isn’t installed, option_space switches to the Sand font.
I just issued a bug-fix request with all of these observations using the Help/Send Feedback on Word menuchoice. Here’s hoping that this will be fixed soon.
At present, the only workaround is to type without issuing the option_space keystroke in the stream of typed characters, then go back and manually select a space character and then type option_space.
Here’s one more curiosity; if one selects the non-breaking character, it is not possible to apply a previously defined character style to it and see the font change to the intended font. So the option_space character itself is infected; this is a problem with Word 2004’s character mapping that probably involves the new Unicode stuff (which has other problems, as you and others have noted).
At this point, I am using an Autocorrect entry to insert the option space. All you have to do is type an option_space keystroke, select the non-breaking space character, and then define an Autocorrect item to have it be inserted where needed in a stream of typed characters. I’ve tested this and find that after inserting the non-breaking space, the typeface that was being used prior to the non-breaking space is still in force. (But on my system, that non-breaking space is in the Sand typeface–it looks like the correct font metric for the typeface in force is used, however, so it looks like this will be an acceptable situation.)
December 3rd, 2004 at Dec 03, 04 | 12:39 am
Barely acceptable, I would say :-/.
Another work-around is, of course, to compose in a TrueType font and then change the font to the desired Postscript font once everything has been typed. (Using a style-based approach, you just have to change the style definition of the main style on which all your other styles are based.) I would tend to prefer that approach.
December 3rd, 2004 at Dec 03, 04 | 1:07 am
Sure, but I’ve noticed that the screen updates are unacceptably sluggish when TrueType fonts are being used in the Normal view, especially after issuing the command-V keystroke to paste in text. With Truetype fonts in place, sometimes the paste results in a corrupted screen, with some of the pasted text overlapping the text already present, and it is necessary to do an up/down scroll to get a proper display. With Postscript fonts (for instance, when using Times New Roman PSMT), this problem does not occur on my system. (I’m using a Powerbook G4 1.33 GHz, so this isn’t a particulary poky system….)
So that’s why I am using the PostScript fonts for now.
December 3rd, 2004 at Dec 03, 04 | 1:32 am
Oh, so all this screen corruption is related to TrueType fonts! I didn’t realize that… I get it all the time too, but I am just used to crappy Microsoft software, so this kind of stuff doesn’t surprise me anymore. I just hit Page Up / Page Down to refresh the screen.
Still, I don’t think I want to deal with the non-breaking space bug rather than this screen corruption. I type too much French stuff that requires non-breaking spaces all over the place.
December 3rd, 2004 at Dec 03, 04 | 2:34 am
I discovered the TrueType = screen corruption deal by accident when doing experiments with different fonts. I am a lot happier with Word 2004 in the Normal view now that I am working exclusively (MathType included) with Postscript fonts. Keep in mind that these Postscript fonts are 8-bit fonts, so the Unicode upper font tables are not present.
I think that the Unicode support in Word 2004 is the problem with the speed of screen response that everyone notes in moving from Word v.X to 2004. The Unicode stuff must be layered on top of the old code, so there are routines gumming up the works that do the font mapping. As we have noted (above) there are a number of manifestations of problems with the font mapping with respect to Unicode.
Still, having the Unicode stuff is a step forward. I recently wrote a paper using FrameMaker in which I found it impossible (using the old Mac 8-bit font system) to type a number of special characters that have to do with “foreign” languages, especially with respect to author names in the bibliography. (For instance, I think that it is impossible to type an i with an accent grave (i.e. an accent pointing to the left as it goes up) using the old Mac fonts. But on windows, which has had unicode support for a longer time, there is no problem with an i accent grave. I had trouble communicating with the journal that published the paper the proper way to accent that i. With Word 2004 this is not going to be a problem any more, but it will be some time (if ever) before all of the bugs in the Unicode support have been worked out fully.
June 21st, 2006 at Jun 21, 06 | 2:27 am
[…] Now, the fact that the bug is unrelated to our localized UI testing doesn’t address the issue that the bug is there, and is bad. Pierre blogged about the bug way back in September 2004. Unfortunately, the MacBU (and the rest of Microsoft, to my knowledge) has never had a good method for customers to report bugs to us. We’ve had the (now defunct) MSWish email address, and we do have the new direct feedback link on Mactopia, but we don’t have anything like Apple’s BugReporter tool. Interestingly enough Nathan Herring, another MacBU employee, just blogged about this specific issue and has some links you may want to read. […]