Missing “Hyphenation” Menu Entry in Microsoft Word due to Corrupted Normal File

Recently, I upgraded to Microsoft Office for Mac 2008 from the 2004 edition. Overall, it turned out to be a welcome improvement, amongst others because it doesn’t crash the WindowServer any more.

However, one issue puzzled me: the “Hyphenation…” menu entry was simply missing from the Tools menu. Simply not there. Nowhere to be seen. In effect, it turned out to be impossible to have Word hyphenate documents.

So I tried everything: I trashed all preference files under ~/Library/Preferences/Microsoft/ and the ~/Library/Preferences/com.microsoft.* files. I trashed all files under ~/Library/Application Support/Microsoft/Office/, which contains the Normal.dotm file. I reinstalled Office. To no avail.

Finally, I turned to Microsoft’s support. Their first working assumption seems to be that anything not working is due to corrupted preferences. So they basically made me repeat all those steps I had performed before. In particular, they suggested trashing ~/Library/Application Support/Microsoft/Office/Normal(.dotm), which I had done. I got a gnawing feeling that this support incident wouldn’t be going anywhere.

Enter fs_usage.

So I traced Word’s startup process using fs_usage and found out that Microsoft’s support has somewhat of a good support script, but it lacks a small but important detail: Microsoft Word looks not in one, but in seven possible locations for a Normal.xxx file, namely:

  1. ~/Documents/Microsoft User Data/Normal
  2. ~/Library/Application Support/Microsoft/Office/User Templates/Normal
  3. ~/Library/Application Support/Microsoft/Office/User Templates/Normal.dotm
  4. /Applications/Microsoft Office 2008/Normal
  5. /Applications/Microsoft Office 2008/Normal.dotm
  6. /Applications/Microsoft Office 2008/Office/Media/Templates/Normal
  7. /Applications/Microsoft Office 2008/Office/Media/Templates/Normal.dotm

In my case, there was an old Normal file, probably left behind by Word 2004, in ~/Documents/Microsoft User Data/Normal! After I removed it (and the file ~/Library/Application Support/Microsoft/Office/User Templates/Normal.dotm, which apparently had become “infected” by the same issue that plagued the old Normal file), the Hyphenation… menu item reappeared!

So there’s two takeaways here:

First, there’s a bug in Microsoft Word 2008 that makes the Hyphenation menu item disappear if the Normal(.dotm) is corrupted in a particular fashion. What exactly is to blame, I don’t know. I only know this is a bug.

Second, whenever you suspect that Word may be misbehaving due to a corrupted Normal file, you should look not only in the default location ~/Library/Application Support/Microsoft/Office/User Templates/Normal.dotm, but in all the seven possible locations mentioned above.

Unfortunately, the only goal of Microsoft’s support seems to be to close incidents as quickly as possible with as little complications as possible. So they didn’t acknowledge that this is quite certainly a bug in Microsoft Office, nor did they seem to be willing to forward any information to the development team at the MacBU, nor did they acknowledge that their support scripts were lacking. Too bad for a missed opportunity to improve future customer support and satisfaction.

Tags: , , , , ,
Categories: ms office

3 comments December 7th, 2009

Data Loss through WindowServer Crashes in Leopard

Fortunately, Mac OS X put an end to those dreaded times when your Mac would crash at least once daily, with all unsaved work lost. That is, almost. At least for me, the issue is back after I upgraded to Leopard in fall, even if the crash frequency is “only” once every one to two weeks.

The symptom is always the same: when typing away in a Carbon (Rosetta?) application on my MacBook Pro, the screen freezes for a few seconds and then goes blue, while the WindowServer starts up again, presenting me with a login window. No need to say that the WindowServer takes all currently open applications with it, in effect trashing all unsaved work.

Digging in /Library/Logs/CrashReporter/ reveals that the crash always happens at the same location somewhere in CarbonCore:

Date/Time:       2009-03-10 17:00:46.770 +0100
OS Version:      Mac OS X 10.5.6 (9G55)
Report Version:  6

Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000be255460
Crashed Thread:  0

Thread 0 Crashed:
0   ...ple.CoreServices.CarbonCore  0x94a47719 UCKeyTranslate + 363
1   com.apple.CoreGraphics          0x929e8937 CGSUniCodeForKeyAndFlags + 152
2   com.apple.CoreGraphics          0x928baee6 CGXCheckForHotKey + 499
3   com.apple.CoreGraphics          0x9288b416 sPostContinuation + 1759
4   com.apple.CoreGraphics          0x929de924 postAfterTapID + 266
5   com.apple.CoreGraphics          0x929df88b postFilteredEventTapData + 496
6   com.apple.CoreGraphics          0x92910ac7 _XPostFilteredEventTapData + 221
7   com.apple.CoreGraphics          0x92810967 CGXWindowServer_server + 117
8   com.apple.CoreGraphics          0x9289bc3b rendezvousHandler + 155
9   com.apple.CoreGraphics          0x9288c70e CGXPostPortData + 158
10  com.apple.CoreGraphics          0x9288c504 CGXRunOneServerPass + 556
11  com.apple.CoreGraphics          0x92888b0f CGXRunOneServicesPass + 377
12  com.apple.CoreGraphics          0x92893e9e CGXServerLoop + 161
13  com.apple.CoreGraphics          0x92821fb9 CGXGetRootAdminCredentials + 0
14  WindowServer                    0x00001ff4 main + 24
15  WindowServer                    0x00001fbe start + 54

So far, I’ve only experienced the crash while I was working in Excel 2004 or Eudora, both Carbon PPC applications that run under Rosetta emulation.

I filed the bug with Apple on 2008-12-05 as rdar://6423987, also see the OpenRadar copy. It was acknowledged as a duplicate of rdar://5432883; Apple says engineering is still investigating.

It seems this bug is somewhat widespread and old (at least going back to December 2007). I could find the following reports that are probably describing the same issue:

Now this sort of bug is extremely exasperating, as it is bound to lead to data loss. Have you experienced the same issue? Please comment below, and, most importantly, file a bug at http://bugreporter.apple.com in which you mention the original Radar ID (5432883) so that Apple gets an idea how widespread the issue actually is.

Tags: , , , ,
Categories: hacking, macosx

20 comments March 11th, 2009

No Fix for Glossy MacBook Pro Screens?

There’s a lot of whining about the new glossy-only screens of the MacBook Pros (and MacBooks, for that matter) just introduced. I generally agree that I don’t like glossy screens, so before I am in the market for a new machine, I thought I’d check options for fixing the problem.

Generally, there are fairly positive reports about fixing glossy screens with anti-reflective films, in particular 3M’s Vikuiti-branded films. I got the impression that glossy screens with anti-glare film applied don’t reach optical qualities of matte displays, but come close. Only downside seems to be that it’s a pain to apply the adhesive film because any dust between screen and film will result in ugly bubbles. So there’s even a version of the film (ARMP-200) that can be permanently laminated onto a display with the help of professional equipment, which comes a bit costlier but will guarantee a lasting quality result.

So today I had a little chat with a German company that’s got a cleanroom and is 3M-certified to apply the ARMP-200 film, talking about ways to fix the new MacBook Pro. Unfortunately, it turns out that the new MacBook Pros have a glass cover (which makes up more or less the whole surface of the lid), under which the actual LCD panel is mounted. While in principle one could laminate a film onto the panel, it wouldn’t fix the problem because the glass cover would still be reflective. On the other hand, one could apply a film to the glass cover, but it seems like it would result in a fairly grainy picture (apparently because the glass is at a fair distance from the actual panel surface). On top of things, there’s no more display bezel under which one could hide the seams of the film, which would make things look fairly ugly. All in all, these guys advised me not to try it.

So it seems to me like it’s pretty much technically impossible to turn the glossy MacBook Pro display into a matte display. Bummer. Of course, other ideas or reports about experiences with anti-reflective films would be highly welcome. Maybe the solution is just whining, after all?

Edited to add: This might be a viable solution (via agilesWissen)

Edited to add: Apple finally added a $50 matte option for MacBook Pros in August 2009.

Tags: , , , , , ,
Categories: default

2 comments October 21st, 2008

Backup Bouncer: A Metadata Test Suite

A year has passed since I published my articles on the state of metadata conservation in Mac backup/file copying software (here, here, here, and here).

It is time for a small update on the matter. Despite the numerous justified requests, I have, unfortunately, not found the time to bake the set of hacked-together scripts that I used for testing into a full-blown test suite. As a result, I have neither amended nor updated my test results in the meantime. My apologies.

In March, inik.net published a disk image with metadata-laden files for test purposes. Based on this set of files, inik.net conducted a new survey of backup and file copying tools. See for yourself for the results; things seem to have slightly improved.

However, the following could be a true breakthrough contribution. Testing for metadata conservation has, up to today, still been somewhat of a voodoo skill, and I’m not surprised that to the best of my knowledge only one person seems to have taken a serious shot at it after my posts. But now, this gaping hole has been filled by Nathaniel Gray with a fully automated test suite for metadata conservation. This could possibly make metadata conservation testing feasible for a wide audience.

I haven’t tested it myself yet, but from what Nathaniel writes it looks very promising. It seems to replace all the tedious manual script runs and BBEdit diff runs that I went through. Great!

I’m excited to see test results for all those tools that I couldn’t test. And eventually, I hope that the state of metadata conservation on the Mac will continue to improve.

Tags: , , ,
Categories: hacking, macosx

3 comments April 28th, 2007

File Creation Dates on Mac OS X: Clash of the Cultures

burnt computer

Yesterday, an interesting discussion about file metadata has begun on darwin-dev. Apple’s Jordan Hubbard argued how file creation dates should not be preserved when copying files.

In this piece, I counter that treating file creation dates as first-class metadata citizens and preserving them upon copying is the more sensible thing to do, and eventually represents the behavior expected by most Mac users.

Tags: , , , , , , , , , ,
Categories: hacking, macosx, unix

Continue Reading 54 comments June 27th, 2006

Apple’s asr Badly Broken in Mac OS X 10.4.6?

In my article The State of Backup and Cloning Tools under Mac OS X, I investigated the metadata preservation capabilities of several command-line utilities, among them Apple’s asr (Apple Software Restore) command-line tool. The same tool is used by the Apple Disk Utility GUI. It seems that its behavior in file-by-file copying mode has changed drastically between OS X 10.4.5 and OS X 10.4.6—see the following table that corresponds to the table in my earlier post. Refer to my earlier post for an explanation of the metadata classes.

ASR (file mode)Apple (10.4.5)x-x?xxx-xxxx-
ASR (file mode)Apple (10.4.6)x-x-x-x-xx---

Basically, the BSD flags (not sure if they were preserved in 10.4.5), the locked flag, HFS+ extended attributes, and ACLs are not preserved.

The conclusion would be that the asr tool, upon which many people rely for backup and machine setup purposes, is badly broken in OS X 10.4.6. This would also invalidate my earlier recommendations made here and here. Can readers confirm this behavior? I’ve filed the bug as Radar #4523878.

Update 2006-04-26: Apple has marked the bug as duplicate, effectively acknowledging it is indeed a bug in asr.

Update 2006-07-11: Apple has not indicated any pertinent fixes in the release notes of OS X 10.4.7, and, indeed, I can attest that the situation is unchanged with respect to 10.4.6.

Tags: , , , , , , , , , , ,
Categories: hacking, macosx, unix

39 comments April 23rd, 2006

Mac Backup Software Harmful

burnt computer

Earlier, I wrote about The State of Backup and Cloning Tools under Mac OS X, where I made the point that copying files on Mac OS X is not trivial because of the metadata associated with files.

I analyzed a variety of file copying engines, most of them command-line tools, and demonstrated how they fare in preserving file metadata.

In this article, I will investigate commonly used GUI backup/cloning tools for Mac OS X. The tools vary widely with respect to their feature set; the features are irrelevant here. I will concentrate purely on the underlying functionality of copying files. A backup tool needs to be able to copy files faithfully for a successful restore in case desaster has struck. The surprising conclusion of my investigation is that almost all Macintosh Backup tools fail at their most basic task, the faithful copying of files.

Tags: , , , , , , , , , , , , , , , , , , , , , ,
Categories: hacking, macosx

Continue Reading 351 comments April 23rd, 2006

Mac OS X 10.4.6’s iSync 2.2 Adds Nokia Series 40 Support

Nokia 6230i

Oh happy news! Apple has today released Mac OS X 10.4.6, which includes the new iSync 2.2. I didn’t consider it possible, but at last Apple seems to have extended iSync support to Nokia Series 40 devices! Nokia Series 40 devices include popular phones such as the 6021, 6230/6230i, and 6820/6822. Until today, iSync support has been limited to Series 60 smart phones.

List of iSync supported devices

This welcome addition finally makes Nokia users who didn’t want to invest in a clumsy smart phone first-class citizens on the Mac, and probably at the same time destroys a large part of the business of third-party developer MacMedia.

I haven’t tried it myself, but will soon. I am curious how practicable the sync mechanism will be.

Tags: , , , , , , , , ,
Categories: default

Add comment April 4th, 2006

Short Downtime

At my web hoster Canhost, three disks in the RAID went ablaze simultaneously. Result: Complete data loss. No further backups. However, I had some fairly recent backups myself; Google Cache did the rest, so the site is back up again now. At least Canhost helped with world-class support, still highly recommended for that reason.

Tags: , , ,
Categories: web

1 comment March 23rd, 2006

The State of Backup and Cloning Tools under Mac OS X


Cloning sheep

Back in the days of OS 9, backing up files was fairly easy. One would just use the Finder to copy files and directories to another volume, and be done. The simplicity, unfortunately, is gone with OS X. Such a simplistic approach is no longer a guarantee to preserve all data faithfully (neither is it a simple or reliable approach for a regular backup procedure). The trouble on OS X is mostly related to metadata, i.e., data about files and directories (such as modification date, file creator/type, Unix permissions, etc.).

Another problem arises when a complete system partition shall be backed up and be bootable later on. Making a backup bootable is not trivial.

Superficially, one could nourish high expectations about the state of backup solutions on Mac OS X, because the underlying BSD Unix core has made all the mature backup and file copying tools that have been developed for Unix systems available on the platform. However, the fly in the ointment is that these tools are generally not aware of Mac OS X metadata and, hence, fail to produce a faithful backup.

This essay will first investigate means to copy files as completely and reliably as possible on Mac OS X, if possible with free and open-source tools. It will conclude with an (incomplete) survey of dedicated backup tools. The tools covered are not only relevant for backup purposes, but also for the case of migrating machines, when the content of one hard drive is to be cloned to another one.

I will not address common features of backup software such as scheduling, backup management, and incremental backups. This piece will be solely about the bare basics of copying files.

The analysis presented here assumes a recent install of OS X 10.4.5 (Tiger) with all updates. The state of backup and cloning tools has already been worse, so there is no need to shoot ourselves into the foot by using outdated tools.


Tags: , , , , , , , , ,
Categories: hacking, macosx, unix

119 comments March 5th, 2006

iChat audio/video chat and file transfer behind NAT

Update 2006-03-10: It seems that the testing servers for natcheck at MIT have been shut down, so natcheck does not work any more. I have added a few more links to the post.

Pretty much all chat applications inherently have trouble stting up a direct connection when both participants are behind a NAT router. Such a direct connection is needed for audio/video chat and file transfer. iChat is one of the apps having notorious problems…

When the router providing NAT has “consistent port translation”, everything should be fine. However, especially some Netgear wireless routers seem to have trouble with this feature.


Tags: , , , , , ,
Categories: hacking, macosx

14 comments March 4th, 2006

Install cvs2svn on Mac OS X 10.4 Tiger

The current version of cvs2svn fails on Tiger with the error message

ERROR: your installation of Python does not contain a suitable
DBM module -- cvs2svn cannot continue.
See http://python.org/doc/current/lib/module-anydbm.html to solve.

That’s because there’s no suitable db module in Apple’s python install. However, there is an easy solution that works with the python 2.3 supplied by Apple:

  • install Berkeley db42 via fink (or however you like)

  • download bsddb3 from http://pybsddb.sourceforge.net

  • unpack and perform inside the unpacked directory

    python setup.py build
    sudo python setup.py install

This should do the job.

See also:

Tags: , , , , ,
Categories: hacking, macosx, unix

3 comments March 4th, 2006