I have managed to solve the problem, with some prodding from a kind reader.

I carefully monitored the reimporting process (i.e. rebuilding of the “Envelope Index” file) and was able to notice that it would always crash when Mail reached a specific mailbox… the mailbox in which I archive my correspondence with my father, of all people.

I also noticed that both the system log and the crash log mentioned this:

Jun 29 09:47:14 Mac-Pro Mail[86791]: *** -[NSCFString stringByAppendingPathExtension:]: cannot append extension 'xls' to path ''
Jun 29 09:47:14 Mac-Pro Mail[86791]: Error: -[NSFileWrapper setPreferredFilename:] *** preferredFilename cannot be empty.

among other things… This led me to suspect that the mailbox with my dad’s archived messages contained a problem message that would cause this Mail crash every time.

I reopened Mail with the old “Envelope Index” file and went to check that particular mailbox. Again, I could see the list of messages, but when I tried to view any of them, I would get a blank window. I then tried to rebuild the mailbox (which, as indicated in the previous post, would normally fix this particular problem), and Mail crashed—with the same error messages in the crash log as above.

In other words, both the general reimport process and the simple mailbox rebuild process would cause Mail to crash when hitting that particular mailbox.

I then quit Mail, opened the “Mail” folder in my home library and located the mailbox folder for my dad’s correspondence. I manually removed it from its location and put it on the desktop.

I then relaunched Mail and tried to import that particular mailbox folder from its desktop location. I got the same crash again, but this time I could see that it was part way through the importing process, thereby confirming that it was occurring when Mail encountered a specific e-mail message.

I couldn’t tell which message from the Mail progress bar or the crash log, but given the mention of “xls” in the crash log, I started to suspect that it was an e-mail with Excel files attached to it. And sure enough, by sorting the e-mails by size in the Finder and using Quick Look to view the contents of the biggest ones, I was able to locate precisely one such message, with two Excel files in it:

I proceeded to remove the offending message manually from the mailbox folder, and tried to reimport the mailbox folder without it. And it worked!

Finally, I quit Mail again, trashed the “Envelope Index” file again, and relaunched Mail, once again triggering the reimport process, but this time with my dad’s mailbox not containing the offending message.

And it worked! Mail managed to go through the entire process of importing over 100,000 messages without crashing.

So that is the solution of this particular mystery. Apparently, there was something in that message with the two Excel files attached that Mail really didn’t like.

I will send the offending e-mail with a bug report to Apple, and maybe they can figure out what causes the problem in this particular case (although I doubt that an isolated problem such as this one will register on their radar…).

I can’t help but find it a bit ironic that Microsoft files are able to give me grief even when I am not using Microsoft products. But that might be a bit unfair; it might just be a coincidence.

Still, it confirms me in my habit of removing attachments from e-mail messages before archiving them. I didn’t remove them in this particular case because it was a couple of files that my dad had asked me to hold on to for a while, until he was sure he had safe copies at home on his own system. At the time, I filed the message away with the attachments and then of course forgot about it. I guess I’ll have to try and be even more religious about removing attachments in the future.

(It also does not help that Mail’s “Remove Attachments” feature is still so badly flawed, which this stupid behaviour of deselecting the message after its attachment has been removed and selecting the next one in the list—or nothing if it’s the last one in the list. I am sure they consider this a “feature,” but I find it a royal pain to have to reselect the message after removing its attachments just to be able to file it away…)

Long-time readers of this blog might remember that I am in fact quite familiar with this procedure, in particular because I was part of the AppleSeed program for the testing of prerelease builds of Mac OS X 10.4 (those were the days) and that I had to do a fair amount of troubleshooting in Mail during those early days of the Spotlight architecture.

So why didn’t I mention the procedure in my post about my recent troubles in Mail?

Well, in a nutshell, the answer is that I could not get it to work, and I was going to try and do more investigating before mentioning it again.

Quitting Mail, trashing the “Envelope Index” file in the “Mail” folder (in the home folder’s library) and relaunching Mail triggers a behaviour where Mail attempts to repeat the procedure that it first used when the user upgraded his system from Mac OS X 10.3 to Mac OS X 10.4, and thus from Mail 1.x to Mail 2.0.

That transition to the new Mail 2.0 required a complete conversion of all existing mailboxes to the new granular file system used in Mail since version 2.0, i.e. a system where each message is saved as a separate file, in order to be compatible with the Spotlight architecture.

When a user first launches Mail 2.0 (or a subsequent version) on a system where the “Mail” folder in his home library is still in the Mail 1.x format, Mail 2.0 gleefully announces that all the existing mailboxes have to be “imported” in order to work with its new file architecture. The user has no choice but to approve the procedure and sit back and watch while Mail 2.0 attempts to convert all existing mailboxes to the new file format.

The reason that I am mentioning all this is that trashing the “Envelope Index” file in an existing “Mail” folder that already uses the new file format triggers the same kind of behaviour. The next time you launch Mail, it tells you that it “needs to import your messages” and gives you no choice but to proceed or to quit the application:

If you click on “Continue,” Mail starts reimporting your existing message files and folders, effectively rebuilding the “Envelope Index” file in the process.

It’s not exactly the most intuitive interface, but this a troubleshooting procedure, so I guess we have to take what we get.

My problem with this procedure on my machine right now is that it systematically fails. Mail starts importing my thousands and thousands of messages, and completes approximately one half of the importing, and then it suddenly, unexpectedly quits.

In other words, Mail never manages to complete the reimporting procedure, including the rebuilding of the “Envelope Index” file, and I am unable to use Mail at all—until I restore the “Envelope Index” file backup that I have kept elsewhere on my hard drive, just in case.

To make matters worse, even after I restore the “Envelope Index” file from a backup and am able to use Mail again, there are some new problems that I have to fix first. For example, this aborted troubleshooting procedure tends to cause Mail to forget all my e-mail account passwords, for whatever reason. So I have to reenter them manually one by one, and even then, sometimes it takes several attempts before Mail actually agrees to remember these passwords properly without asking me to reenter them each and every time it checks for new mail.

The aborted troubleshooting procedure also tends to cause all kinds of problems in my mailboxes themselves. They seem intact and I can see individual messages is them, but when I double-click on the messages to open them, Mail displays a window whose contents are totally empty. I then have to select the affected mailbox, and use the “Rebuild” command. After that, things work normally and I am able to read my messages again. But I have hundreds of mailboxes and I don’t fancy having to rebuild each and every one of them.

Finally, the aborted troubleshooting procedure also seems to cause all kinds of problems with Spotlight. When I try searches on the “Entire message” in Mail, typically I only get an incomplete list of results. There are many items that do contain the searched string that are simply not there in the list of results. This problem seems somewhat connected to the previous one, in that, after I rebuild the mailbox containing the items missing from the list of search results, and repeat the search, then they finally appear in the list of results.

All this is to say that, unfortunately, at this point in time, the troubleshooting procedure consisting of trashing the “Envelope Index” file is not working too well for me. In fact, it’s not working at all, so I don’t know whether it would help fix the sudden sluggishness in Mail.

The only other thing that I have tried is to use a third-party utility tool (OnyX for Leopard) to rebuild Mail’s Envelope Index. OnyX has an option just for this, and I have tried it. But I am not sure exactly what it did and what it repaired, because it did not take very long (only a fraction of the time it would take for Mail itself to rebuild it) and the “Envelope Index” file does not seem to have changed much. It is still the same size and still has an old creation date.

(I am also not sure whether what OnyX did had anything to do with the other problems that I experienced in Mail while attempting to troubleshoot my sluggishness problem, i.e. the blank window messages, the password issue, and the lack of Spotlight search results.)

So until I find a reliable way to rebuild the “Envelope Index” file, I am afraid I won’t be able to fully verify whether that is what it takes to fix Mail’s sudden sluggishness and get rid of these pesky “Loading…” messages. For now, I have no choice but to continue to use my (possibly corrupted) existing “Envelope Index” file and hope for the best…

I am always careful to remove attachments before filing messages away (I save the attachments that I need to keep elsewhere before removing them), so that the total size of my “Mail” folder does not become unmanageable. But I do keep the messages themselves, and according to Mac OS X’s Finder I now have over 100,000 items in that folder, for a total size of over 1 GB.

Most of these messages are filed in specific mailboxes, so that my main account mailboxes (Inbox, Sent, Junk, Trash, and Drafts) are reasonably lightweight.

Until recently, this situation did not seem to be a problem for Mail, which was performing adequately on my three-year-old Mac Pro.

For some reason, however, a few weeks ago, Mail started displaying an unmistakable level of sluggishness. And when I say “displaying,” I mean it:

This is what I am now getting far more often than I would like when I am doing a very simple thing such as opening a message in a separate window to read it.

The message’s contents do appear eventually, but it can take several seconds, and there is absolutely no apparent reason for this delay.

It tends to happen more frequently when I try to open a message to read it while Mail is still in the process of sending a reply to another message. (My Internet connection is not very fast, so that can take a few seconds, even for sending a small message.) But it also happens when nothing else is going on in Mail. (I keep the Activity Viewer window open at all times in order to be able to monitor Mail’s various processes.)

This never used to be a problem in Mail, which, on my Mac Pro, was, until recently, perfectly able to handling multiple tasks simultaneously without any noticeable delay and was certainly able to open a message window and display the message pretty much instantly.

I haven’t changed anything to my settings or my hardware configuration, and there haven’t been any significant software updates that would explain such a change. And it’s also hard to imagine that, after several years of being able to handle thousands of messages without problems, Mail would all of a sudden have somehow reached a limit and lost its ability to perform at an acceptable pace.

I should stress that this is not a problem with the Mail UI itself, which remains responsive at all times. The problem is with the threads that the UI triggers.They all appear as separate processes in the Activity Viewer, with a progress bar and a “Stop” button for each (although some “Stop” buttons are greyed out and cannot be clicked on). Even the simple process of double-clicking on a message to open it in a window triggers a couple of threads that appear in the Activity Viewer.

Normally they just flash by and the message opens almost instantly. But now I see these threads stay there in the Activity Viewer for several seconds while Mail seemingly struggles to complete them (and displays the above-mentioned “Loading…” message in the message window instead of the actual message contents). I can still do other things in Mail or elsewhere in the meantime, but that is faint consolation. I don’t think I should have to wait several seconds for a message to open in a window so that I can read, especially when that message is just plain text with no pictures and no fancy “rich text” code.

I have tried various things, such as “rebuilding” my Inboxes (with the “Rebuild Mailbox…” command). But it has all been to no avail. Mail still is significantly more sluggish than it used to be when it comes to completing its various threads of activity. (Again, the UI itself is not sluggish. It’s only the threaded processes. But since pretty much everything that the user does in Mail triggers one such process, it very much affects the very usability of the application.)

Did Apple make some kind of change in the Mail code in a recent Mac OS X 10.5.x update that would have caused this problem to crop up? It’s quite possible. But it would be mighty hard to prove, especially since I don’t have a specific date for the moment this problem started happening to me on my Machine.

In all likelihood, what will happen is that I will have to live with this new problem for a few more months, and then Snow Leopard will come out with its many promised improvements in performance, and things will be better again. At least that is the best I can hope for at this stage, I am afraid.

Hi Pierre,

This is a courtesy email regarding Bug ID# 6951559.

Engineering has requested the following information in order to further investigate this issue:

That’s a GPU restart.  Have you been able to sample or Shark the app/system when it hangs?  If you can ssh in, /usr/libexec/stackshot will also give you stack info for all the threads in the system.  Can you please attach that information so we can take a look?

So the problem I am experiencing is a “GPU restart,” which presumably is not a very good thing, and most definitely involves the graphics card.

I replied to this e-mail saying that when the system hangs, it becomes totally unusable, so that I cannot use the Activity Monitor application to capture a “sample” of the affected application (most often Preview), but if there is a way to “sample” the application or the system remotely via ssh, I would be more than willing to give it a try, provided that they gave me some further instructions.

If, the next time the problem occurs, it does not cause a complete system hang, but only a scrambled display in the foreground application, I will also try to sample the affected application locally, provided that the video scrambling does not extend beyond that one application.

I also told them I would try to locate that “stackshot” thing remotely via ssh the next time it happens.

The interesting thing, though, is that the problem hasn’t occurred since. And the only thing that I have done is that, following a reader’s suggestion, I have opened up my Mac Pro and cleaned the dust that had accumulated inside the machine.

I didn’t really find any dust on the graphics card itself, which is a GeForce 7300 GT and does not have a fan, only a heat sink. The card is also located very close to the metallic enclosure for the RAM slots, which means that there isn’t much room for dust to accumulate anyway. Still, I tried to clean as much as I could elsewhere in the machine. There wasn’t tons of dust, but there was some.

And, since I have done that, I haven’t had a single occurrence of the problem. (It’s been four days now.) It’s not conclusive yet, but it does seem to suggest that there might be some truth to the theory that the problem might be caused by overheating of the video card due to poorer air flow. I guess we’ll see if my experience confirms this in the longer term. (It still seems strange that the problem would only have surfaced with recent Mac OS X 10.5 updates, and that some people appear to be able to eliminate the problem by reverting to an earlier version of Mac OS X 10.5. Maybe that means that there was a change in the graphics driver in more recent versions that somehow made the system more sensitive to heat issues. It’s hard to tell.)

The only problem with all this is that, since I cleaned my Mac Pro, I have noticed that its normal noise level appears to be somewhat higher than it used to be. The Mac Pro has always been a fairly quiet machine, and I have become used to the low level of noise, so I cannot help but notice that the machine is now somewhat noisier. There is a bit more of a hum than there used to be.

I reopened the machine and rejigged everything to make sure that nothing had become loose following my initial clean-up. But there really isn’t much room for anything to wiggle or hang loose in a way that would increase the fan noise level as far as I can tell. I only opened the side door, took out the graphics card and put it back in, and also took out the RAM cards and put them back in after removing the dust. I didn’t really move anything else. (The second time, I also took out the hard drives and put them back in, but that didn’t help with the noise either.)

The only abnormal thing that I noticed while the machine was open was that the three grey lozenge-shaped foam pads that are normally stuck along the bottom of the metallic door and presumably serve to provide a tight fit and prevent the door from vibrating had become unglued. But I put them back in their original position (I can still see the outline of the glue on the door) and pressed them on so that they would stay in place. So they are back in their right place now and, even though they still come easily off when pulling on them because the glue has dried, they should still work as expected when they are in place and the door is closed. So I don’t suspect that they are the cause of the increased noise.

Maybe it’s just the general aging of the machine (it’s three years old), which I might have precipitated somewhat by opening it and closing it. The weather is also warmer, so there is a higher chance of things overheating a bit and causing an increase in fan activity, although I never hear things ramping up. (The noise level is always constant, and is the same as soon as I turn the machine on, even if it’s cold.)

The higher noise level is not going to drive me crazy or anything, but it is a bit annoying that this whole problem with the NVIDIA card has caused more lasting consequences, which I don’t seem to be able to do anything about now.

As for the original problem, I guess I’ll just have to wait and see if it reoccurs. (Other readers indicate that they have been experiencing problems since the Mac OS X 10.5.2 graphics update. I do remember that at some point Apple shipped a separate graphics update, before folding it into the main system update, probably. And it’s a problem that seems to affect cards other than the 7300. One reader mentions the Quadro FX4500.)

Consider the following situation:

This is a section of a long document, where I have a heading with an automatic number (or letter, to be accurate) of “H,” followed by a table.

I want to move that table up so that the heading will move to the right to flow with the rest of the text on the right-hand side of the table.

So I grab that weird proxy control that is supposed to let you move a table around and I lift it up:

And then I drop the table in its new location:

WTF?

I just moved the bloody table, and Word 2008 changed the heading’s automatic letter from “H” to “A”!

Why does it do this? I have no idea. It’s not like there any kind of hidden section break or anything like that between the heading and the text that might explain (but not justify) the existence of such a bug. There is nothing else on this page, only the table and the heading and the text. What am I supposed to do here?

I am not making this up. It’s happening to me here right now. If it were up to me, no one would use Word’s automatic numbering feature in their documents. But people do. And I have to deal with it in the resulting documents that I have to work on.

It’s maddening. And it’s not an isolated incident, of course. There are hundreds of such problems in Microsoft Word that one has to deal with on a daily basis. It simply is a totally unreliable piece of crap.

Of course, Microsoft’s developers would probably argue that it’s a “minor” problem, that it does not cause the application to crash, so they have worse problems to address first.

Well, yeah, except that Word’s automatic numbering feature was introduced more than 10 years ago and it’s still full of bugs. It’s not just that these bugs are a low priority. It’s that they never get fixed. Ever.

Microsoft’s engineers seem to live in a parallel universe where only application crashes are important bugs (and even then, they still can’t make a Mac OS X application that does not crash; I have numerous crash logs to prove it) and all the rest is just stuff that people have to learn to live with.

That’s not the world in which Mac users live. They expect quality applications, applications that not only never crash, but also are reliable in daily use and in which key features work as expected, and not in totally unpredictable and uncontrollable ways.

Microsoft is simply totally incapable of delivering such an application.

So I thought I should clarify a few things. First of all, my blog is not a journalistic endeavour. I do not have the resources to fully investigate each and every issue that I touch upon in my blog posts. (I have a full-time day job, blah blah blah.) My blog is primarily a highly personal (which, in the eyes of some, probably means highly biased) account of my own experience using, among other things, Apple computers and Mac OS X software.

That said, I am of course more than willing to further explore an issue when the feedback I get raises my level of interest. It’s just that I cannot and will not do it systematically, especially since I have no way of predicting which of my posts will attract the attention of a high-profile writer like John Gruber and of his own readership.

In this particular case, several readers wrote to point out the existence of a full-page zoom feature in various other browsers, including Firefox 3, Opera, and… Internet Explorer 8.

Needless to say, since Explorer 8 is a Windows-only product, it’s not really relevant to this particular discussion. I am glad to hear that Firefox is also generating some healthy competition on the Windows side and leading to improvements in the web browsing experience for many users. But it’s not exactly likely to make me or my fellow Mac-using readers want to switch to Windows.

Both Opera and Firefox are available for both Mac OS X and Windows. And yes, both of them also include a page-zooming feature similar to the one introduced by Apple in Safari 4. In the case of Firefox, the feature has been available since the release of version 3.0.0, a year ago. (The Wikipedia entry on page-zooming also mentions iCab and Amaya.)

Does all this make the availability of the feature in Safari 4 somewhat less impressive than what I expressed in my post yesterday?

It means, of course, that the feature was not invented by Apple. But I didn’t actually say that in my original post. I just said that I was impressed with Apple’s implementation of the feature. I did mention that Firefox 3 also had a similar feature, although of course I didn’t say explicitly that it had already been available in that browser for a year. (Internet Explorer 8 only came out a few months ago. And I don’t know the exact history of the feature in Opera, but according to an e-mail I got from an Opera staff member, the browser was the very first to introduce such a feature, a long time ago.)

What I also said, however, was that, even in my (very) limited testing, the implementation of the feature in other browsers was not as good as in Safari 4. I tried the page-zooming feature on the web site that I am in the process of developing in Firefox 3, and as soon as I zoomed out by one notch, some of my CSS buttons became misaligned. (They stayed aligned properly when I zoomed in.)

Now, it is of course possible that there is a flaw in my own CSS code, and that Firefox 3 reveals that flaw whereas Safari 4 does not. But I would find this somewhat surprising, given that my site scales perfectly at all sizes in Safari 4, and it really is not a very complicated design. I am afraid I don’t have time at this point to further explore the issue, but I suppose I will have to do so eventually, since I can assume that a number of people will be browsing this site that I am designing with some flavour of Firefox, and that they will encounter the issue if they try to zoom out of my site, for whatever reason.

But if it turns out that it is a bug in Firefox’s rendering engine that I have to work around, then it will simply confirm me in my view that Safari is a better browser. (On the other hand, I get a similar problem in Internet Explorer 8 as well when zooming out of the site, so maybe it is a problem with my code after all. Or maybe it’s a problem in both Firefox and Explorer… For what it’s worth, I cannot reproduce the problem in Opera. I haven’t tried iCab.)

As for Opera, it has another problem, which is even worse: It does not even display my buttons properly at the default zoom setting! Here’s what one of my buttons (made with CSS) looks like at normal size in Safari 4:

Here’s what the same button looks like at normal size in Firefox 3:

And here’s what the same button looks like at normal size in Opera 10:

Oops. It gets even better. Here’s what the same button looks like when I zoom it by one notch in Opera:

If you look carefully, you’ll see that there isn’t just a problem with the fact that the button label does not fit in a single line. There is also a very serious problem with the vertical alignment of the initial capitals in the text styled with small caps (and the same problem occurs in other occurrences in small caps on my site’s pages). So clearly there is something very wrong with the font rendering engine used by Opera, which already affects the default zoom size and causes a right old mess as soon as you zoom in.

The moral of the story here is that I don’t mind being Daring-Fireballed at all, and I don’t mind constructive criticism, and I don’t mind spending some time further investigating a specific issue when readers write to me to point out what they feel are shortcomings or gaps in my posts. But that does not necessarily mean that it will lead me to revise my position, quite the contrary!

While some of my posts (mainly due to a lack of resources) can be more about a “gut feeling” than a proper investigation of everything that’s out there, I have found, over the years, that my gut has not often been wide off the mark. And so I will probably continue to mix the two in the future, even if it irritates some of my (occasional) readers. After all, nobody is forcing anyone to read any of this stuff.

I am pretty sure that one of the reasons why Microsoft’s engineers (if you can call them that) have failed to fix the problem after that many years is that they haven’t put much effort into trying to reproduce the problem.

Well, if any MacBU employee cares, I guess I should report something that I have noticed consistently over the past few months. In Word 2008 at least, I able to reproduce the problem each and every time I copy something in a Word document and then use my AppleScript script to paste the contents of the clipboard as unformatted text elsewhere in the document.

The script I use for this is the one suggested by Joe Kissell in the comments on my blog post about pasting as unformatted text in Word 2008, i.e.:

tell application "/Applications/Microsoft Office 2008/Microsoft Word.app"
	tell selection
		try
			set theClip to Unicode text of (the clipboard as record)
			type text text theClip
		end try
	end tell
end tell

The script works fine (although there is often an annoying delay before it kicks in, due to the general slowness of Word 2008), but each and every time I use it to copy and paste without formatting something in a Word document, at the same time I paste the text, Word 2008 adds an “OLE_LINK” bookmark to the original chunk of text that I just copied.

This does not occur when I use the “Paste Special…” command in the “Edit” menu and then choose the “Unformatted Text” option, which is obviously a much more cumbersome process. It only occurs when I use my AppleScript script, to which I have assigned the command-option-shift-V shortcut.

But still… it occurs each and every time. This is now officially a 100% reproducible bug as far as I am concerned.

Of course, Microsoft’s engineers, since they are (or believe themselves to be) software developers and not actual users, probably don’t realize how important it is, in the real world, to be able to paste unformatted text as opposed to text with its original formatting, which is why the command is so difficult to access in the standard Word 2008 interface (if you can call it that) to begin with and why any serious Word user would want to create a script and a shortcut for it.

And Microsoft’s engineers probably also don’t ever bother to make bookmarks visible in their Word documents, which is another condition required to actually notice the bug, since it works invisibly behind the scenes.

In an ideal world, Microsoft would have a proper bug reporting mechanism and not just some kind of crappy generic feedback page. And in an ideal world, Microsoft would actually read this feedback and take it into account.

In that ideal world, I would actually bother to submit the bug as a bug report to Microsoft. But in the real world I will not, for the very reasons that I have mentioned several times over the years and that are summarized in my “About” page.

If there actually is a Microsoft employee out there who cares, well, he or she will have to make the effort to read this blog and reproduce the bug themselves and then do something about it—you know, just like that Firefox developer who spontaneously contacted me this morning after reading my blog post about the full-page zoom feature in Safari 4 and Firefox 3 to let me know that he had filed and fixed the alignment bug in Firefox 3 that I had incidentally described in my post and illustrated with a screen shot.

Now that’s what I call a developer. (It won’t convert me into a Firefox user, because there are a number of such flaws in the software and I still don’t find the browser Mac-like enough, but it is still impressive that the developer noticed my blog post so quickly and did something about it right away.)

I should also mention that, a few months ago, a Betalogue reader, Rob Gilpatric, wrote me an e-mail to describe a VBA script that can be used for removing the spurious bookmarks:

Sub NoMoreOLEBookmarks()
' Word for Mac has this annoying habit (in some documents, but not all) of creating a bookmark each time you cut and paste text. _
' After a while, you can accumulate hundreds of these bookmarks. _
' This macro automatically cycles through every bookmark and deletes it if its name begins with OLE_LINK.

Dim bkmk As Bookmark
Dim n As Integer

For Each bkmk In ActiveDocument.Bookmarks
If Left(bkmk.Name, 8) = "OLE_LINK" Then
bkmk.Delete
n = n + 1
End If
Next bkmk

If n > 0 Then
MsgBox n & " bookmarks removed!" & vbCr & vbCr & _
"(Brought to you, courtesy Rob Gilpatric)", vbOKOnly + vbInformation, "No more OLE Bookmarks"
End If

End Sub

Of course, the script cannot be used in Word 2008, since it no longer supports VBA. And I don’t think I am going to try to “translate” this script into an AppleScript script. I don’t really have the time, and it doesn’t really fix the problem anyway. It just gives you a somewhat quicker way (than the manual way) to remove the bookmarks when you have finished working on your document. But you still have to remember to use it each and every time…

Am I really the only who’s strongly bothered by the fact that the Firefox developers don’t seem to care about vertical alignment?

This is one of the main reasons why, when it comes to web browsers, I tend to stick with Apple’s own offering, even if I occasionally use other browsers when I have to.

All of this is to say that, while other (non-UI) features in a browser are important too, I tend not to pay as much attention to them. And so I tend not to read about them and only to find out about them when I encounter them in my daily activities.

This is exactly what happened to me yesterday with Safari 4’s Full-Page Zoom feature. I was working on a web site that I am developing, and I wanted to check how the site scaled when using the browser’s zoom feature. This was an issue that I had been struggling with on this particular web site—probably because web site development is not a full-time job for me and my mastery of CSS leaves quite a bit to be desired still.

Much to my surprise, I discovered that my site now scaled almost perfectly! I immediately knew that it had nothing to do with my own code, which had not changed, and that it had to be related to the fact that I was now using Safari 4 instead of Safari 3.

And sure enough, when I went to Apple’s promotional pages for Safari, I quickly found that this was a new feature in Safari 4 and that it even had a name, “Full-Page Zoom.”

I must say that this discovery leaves me mightily impressed. There is just no comparison between how Safari 4 scales pages and how it used to be in previous versions of the browser, or how it still is with several other browsers. Instead of just making the text bigger, with sometimes rather unsightly consequences in the way the page is rendered (depending on how well the site has been designed to scale properly), now Safari scales everything, including the pictures (doing its best to smooth the edges in low-resolution logos and photos), and it does so instantly, with a near-perfect consistency and overall sense of proportion and positioning.

Some other browsers (including Firefox 3) might be attempting to match Safari 4 in that department, but they are simply not as good at it, at least not based on my (admittedly limited) testing.

This is a feature that makes perfect sense and I am glad that both Firefox and Safari are moving forward in that direction. It not only improves the usability and readability of the sites, but it also makes a web developer’s job significantly easier, because he no longer has to worry about how his text will scale when his pictures stay the same size and remain in the same position.

Based on the obvious advantages of full-page zooming, I can’t imagine that it will take too long for it to become the standard behaviour for the zoom feature in all web browsers. And that’s very good news for both users and developers.

(There are still some kinks to iron out. For example, the site I am working on was designed to be horizontally centered on the page, using a position 50% from left and then a negative left margin of half the width of the site—a perfectly legitimate way to do it as far as I know. When I would zoom in too far, however, either with Firefox or Safari, the left-most area of the page would extend beyond the left edge of the window, but there would be no room on the horizontal scroll bar to scroll further to the left. I ended up switching to “auto” for the left and right margin instead in order to get the page’s contents centered.)

So I have been experiencing the limitations and flaws of Apple technology in low-bandwidth situations for many years now, and I am afraid the latest “improvement” in Safari 4, namely the replacement of the blue progress bar in the address bar with a spinning wheel, is yet another illustration of the fact that Apple does not care about the needs of users in low-bandwidth conditions:

The only way to explain why this is a big step backwards is to analyze the purposes that a progress indicator fulfills. In my view, a progress indicator has at least two purposes:

1. It gives the user an idea of how much of the process has been completed and how much remains to be completed.
2. It indicates to the user that something is taking place, that progress is being made when all other visual indications are that the process is stalled.

The blue progress bar in the previous versions of Safari fulfilled both purposes:

It gave an idea of how much of the page had been loaded because the length of the field for the site’s URL doubled as an indicator of the estimated length of the entire loading process and the length of the blue bar within that field was an indicator of how much of this length had been covered.

And it indicated to the user that something was taking place not just by being there, but by moving along, i.e. by changing its state gradually, in real time, as the page was being loaded.

And that’s a crucial distinction. Because sometimes the blue bar would stay there, but would stop moving. This was not just an indication that the loading process was still in progress, but that it was actually stalled.

In my low-bandwidth working conditions, this happens fairly often. For whatever reason, the connection to the server gets lost, and Safari is unable to continue loading the page. Safari has a built-in mechanism that instructs it to give up on the process altogether after a while, presumably through some kind of “time-out” countdown. In other words, if the server hosting the page fails to respond for more than 1 or 2 minutes or whatever, then Safari interrupts the page loading process and displays an error message instead.

The key thing here was that, with Safari 3, I didn’t have to wait until the end of the time-out delay and the display of the error message. If I saw that the blue progress bar was stuck for an extended period of time, I could simply interrupt the stalled process by clicking on the Reload button and force Safari to try loading the page again.

Now, with the spinning wheel, this level of accuracy in the depiction of the page loading process has been completely lost. All you get is a spinning wheel. All that the spinning wheel denotes is that the page loading process is in progress. But there is no way to tell whether the process is stalled, because the wheel keeps turning anyway. The spinning wheel activity is not the equivalent of the blue progress bar marching forward, i.e. changing. It is only the equivalent of the presence of a blue progress bar. It makes not distinction between whether the process is moving along or stalled.

And that is the most crucial aspect of the blue progress bar that has been obliterated by Apple.

Obviously, in Apple’s world, all Internet connections are fast, pages load very quickly, and the page loading process never stalls. But that is not the real world, especially not for users in low-bandwidth conditions. For such users, stalls happen all the time. And now with the spinning wheel in Safari 4, there is no longer any visual indication of such stalls. The only way that you can tell that the process is stalled is by waiting until Safari times out and displays an error message, which can take several minutes.

It’s a big step backwards in functionality.

Now, there are ways to mitigate the loss. As someone who has had to endure low-bandwidth conditions for many years, I have always relied on a bandwidth monitoring tool. The tool that I use is MenuMeters. It is a free piece of software that can add a variety of visual status indicators to your menu bar, including a network activity indicator:

This indicator shows me whether there is any transmitting/uploading (red arrow) or receiving/downloading (green arrow) activity, and is updated every second with a value in KBytes per second indicating how much data is being transmitted.

Thanks to this indicator, if the page loading process in Safari 4 stalls, while the wheel keeps turning and gives me no indication that the process is stalled, I can see that the amount of data being received drops down to 0 KB/s.

A value of 0 KB/s does not necessarily mean that the process is completed stalled. Sometimes the value drops for a few seconds and then goes back up, depending on the responsiveness of the server and various other conditions.

But if the value stays at 0 KB/s for a long time, then it’s a pretty strong indication that something is wrong and that the process is stalled.

Of course, MenuMeters is no help if I am loading several different things at the same time. If only one of them is stalled, the other things will continue to generate network activity and I will have no way to tell in the MenuMeters indicator that one particular process is stalled.

That’s when I also use another third-party tool, the Network Monitor provided by Little Snitch.

This network monitor does not just display the overall level of network activity, like MenuMeters does; it also breaks it down per application. So if I have a download taking place in an application other than Safari and Safari is trying to load a page at the same time, I can see in Little Snitch’s Network Monitor whether both processes are still progressing or if only one of them is generating any network activity.

And even when I have several concurrent downloads taking place simultaneously in Safari, I can still use Little Snitch’s Network Monitor to monitor them separately, because the Network Monitor constantly updates its display with the addresses of the sites from which the data is coming. So when I have two downloads in progress in Safari, one from server1.com and the other from server2.com, if I don’t see Little Snitch’s Network Monitor alternating between “server1.com” and “server2.com” in its display on the Safari line, I know that one of the processes is stalled, and I can try to do something about it (i.e. hit Reload).

All this is to say that, thanks to these other third-party tools, I will be able to survive with Safari 4’s “new and improved” visual indicator, which no longer gives me as much information as the blue bar used to do.

But I am still quite disappointed that Apple has chosen to replace the blue bar with this spinning wheel. Because the bottom line is that this spinning wheel only says one thing, and that is that the loading is in progress. That’s it. There is no indication of the rate or speed at which it is progressing, and there is nothing that shows if the process is stalled.

What is paradoxical is that the very assumption that Apple seems to be making here, i.e. that everyone has a fast connection and does not need a detailed progress indicator, ultimately means that, in Apple’s view, we don’t need a progress indicator at all. After all, if connections are so fast and pages load so quickly, where is the need for indicating progress? You might as well get rid of the process indicator altogether, and just assume that all pages load almost instantly and the user does not need to know anything about the downloading activity.

In fact, I wouldn’t be surprised if, following their own logic, Apple’s engineers did decide to remove the progress indicator altogether some time in the future. There are already plenty of other examples in the Mac OS X UI of processes that are far from instantaneous and yet the UI is designed to behave as if they were instantaneous, with no progress indicators of any kind. What you end up with then is a UI that fails to respond instantly to your interactions, and you have no idea why, and you have no idea how long it will take for it to respond, and all you can do is wait until the computer finally lets you regain control.

This is precisely what’s so despicable about computers as modern tools: situations where the computer, and not the user, is in control. Everything in the UI should be designed so that the user never loses control of what is going on. If a process takes time, then the user should be given an indication that is as accurate as possible of how long the process will take, and should be able to continue doing other things in the meantime. This is the only way to maintain the fluidity of the interaction between the user and the machine, and the only way to ensure that the user stays in control.

By replacing the blue progress bar with a spinning wheel in Safari 4, I am afraid Apple’s engineers have once again ignored that fundamental design rule and given us software that pretends to know better than we do what we need from it.

It’s arrogant. It’s insulting to the many users who do not enjoy high-bandwidth working conditions. And it is the ugly side of Apple’s relentless push towards the future.

I would very much like Apple to come down here in my little corner of southwest Nova Scotia and install a direct optical fibre connection to the main data centers in the provincial capital so that I get near-instantaneous access to all my favorite web sites. Until this happens, any other move by Apple that assumes that every one has a high-bandwidth connection to the Internet will be yet another confirmation that they don’t care about users like me.

Recently, I have started experiencing problems that seem to be related to the graphics card. I am not sure exactly when they started, but I strongly suspect it was with the Mac OS X 10.5.6 update. The symptoms are the following: Usually, I am in the process of opening a PDF file with Preview when, all of a sudden, either the display becomes completely corrupted, with pixelation everywhere and bits and pieces of windows everywhere, or the entire UI freezes and the mouse pointer, while still moving, turns into the spinning pizza of death.

When the symptoms are “only” display corruption, I seem to be able to solve the problem by quitting and relaunching the Preview application itself.

When the symptoms are a total UI freeze, I cannot do anything to regain control of the system. The force-quitting shortcut does not work, and nothing responds to mouse clicks. I have to do a hard reset of the machine.

It’s a problem that has been happening on and off for the past couple of months now. Sometimes I get a few days without any problems. Sometimes it happens a couple of times in fairly quick succession.

Whenever the problem occurs, if I look in the system log in Console, I find a flurry of error messages at the time of the display corruption/hang that seem to have to do with the NVIDIA graphics. They all look like this


Jun 8 15:44:57 Mac-Pro kernel[0]: NVDA(OpenGL): Channel exception! status = 0xffff info32 = 0×6 = Fifo: Parse Error
Jun 8 15:44:57 Mac-Pro kernel[0]: NVDA(OpenGL): Channel exception! status = 0xffff info32 = 0×3 = Fifo: Unknown Method Error


To me, this looks very much like there is a problem with the OS software that controls the graphics card, i.e. the video card driver for the NVIDIA card.

Of course, at this point it is impossible to entirely rule out a hardware failure of the graphics card itself, but I have done a bit of research online and found that I am far from being the only one with the problem:

MacFixIt Forums: “Display corruption and hangs using OS X 10.5.6”

Apple Discussions: “NVDA(OpenGL): Channel exception!”

I have another spare GeForce 7300 GT so I might try to swap the cards to see if it makes any difference. But really, based on the apparent prevalence of the problem and the variety of systems affected, it does appear to be not a widespread hardware failure, but an OS-related issue introduced with the Mac OS X 10.5.6 update (unless these GeForce cards are all starting to fail after a few years of daily use).

Sadly, as always in such situations, it seems to be hard to get the message across to Apple that there might be a problem with their drivers. Some people appear to have more success than me in reproducing it reliably, by using software applications that make greater user of the graphics card and presumably of the OpenGL software. I have submitted a bug report, but of course haven’t heard anything back from Apple about this.

It is really quite frustrating because, with the transition to OS X, we really thought we had left system-wide crashes and hangs behind us. But every once in a while, they seem to be able to rear their ugly heads again, in a way that really affects the perception of trust in the machine. In my case, the situation is not too atrocious yet, since the problem does not occur every day. But I still expect to be able to run my machine for many days in a row without having to reboot or risking to lose any of my work, and at this point I seem to have lost that level of reliability.

Of course, Quick Look is first and foremost a Finder feature, so its use in other applications, even Apple’s own, is a bit of a hit-or-miss proposition. But it does work in other applications as well. For example, it works in Mail when you are viewing a message that someone sent you with an attachment. If you select the attachment’s icon in the message and press Space, Mail does display a preview of the attachment’s contents.

So it’s quite easy to get into the habit of using Space as a shortcut for previewing files in Mail as well.

Unfortunately, it does not work everywhere. For example, if you are in the process of composing a message in Mail and you insert a file attachment in your message, you cannot select the attachment’s icon and press Space to Quick Look it. If you try to do that, Mail actually interprets the Space keystroke as meaning that you want to insert a space character and writes the space over the selection, deleting the attachment!

Fortunately, there is still a way to use Quick Look to preview a file attachment even when composing messages. But you must refrain from using the keyboard shortcut for Quick Look. Instead, you can right-click on the attachment icon. “Quick Look Attachment” is one of the commands in that contextual menu, and it will let you peek inside the attachment.

I still find myself accidentally pressing the Space shortcut to Quick Look an attachment from time to time while composing a message, because it is simply impossible to remember that this only works when the attachment is in a non-editable message. But of course it’s easy to undo the accidental entry of a space character over the attachment, with command-Z, which restores the attachment. Then right-click to bring up the contextual menu works as an acceptable substitute.

Because of this, I tend to notice problems that might not be apparent to Mac users who do not use Full Keyboard Access and that tend to suffer from a certain amount of neglect on the part of Apple’s engineers.

For example, a while ago I pointed out that the tab order for the various controls in Pages ’08’s “Find/Replace” dialog box was wrong. This was a problem that was only really apparent if you had Full Keyboard Access on and used the Tab key to cycle through all the controls in that dialog box, including not just the text fields, but also the pop-up menus, the buttons, etc.

Thankfully, Apple fixed the tab order in Pages ’09.

But there is still another problem with Full Keyboard Access in the “Find/Replace” dialog box that remains unaddressed in Pages ’09. It has to do with the behaviour of keyboard shortcuts when the focus is on a control other than a text field.

For example, after having turned Full Keyboard Access on, bring up the “Find/Replace” dialog box, switch to the “Advanced” tab, and then type a text string in the “Find:” field.

Then press command-A to select the text string you’ve just typed and press command-C to copy it to the Clipboard. While the focus is on the text field, these two keyboard shortcuts work just fine.

Now press the Tab key repeatedly to move the focus to the “Replace:” field, with the intention of pasting the contents of the Clipboard once you’re there. If you have Full Keyboard Access on, it takes quite a few Tab keystrokes to get there, because Tab cycles through all the controls and not just the main ones.

So it’s relatively easy to overshoot or undershoot by one keystroke. So let’s say that, accidentally, you press the Tab key one time too many and you end up putting the focus on the “Insert…” pop-up menu next to the “Replace:” field, rather than on the “Replace:” field itself:

Now if, like me, you tend to work fast and do this type of thing repeatedly throughout the day, you might do the next step, i.e. press command-V to paste the contents of the Clipboard, before you actually notice that the focus is on the wrong control.

And that’s where things get, let’s say, interesting. Since the focus is on the “Insert…” pop-up menu and not on the “Replace:” text field, Pages ’09 should just ignore the command-V shortcut, since it has no relevance when the focus is not on a text input area.

But it does not. Instead of ignoring the shortcut, Pages ’09 actually inserts the contents of the Clipboard in the main document window in the background behind the “Find/Replace” dialog box!

And the problem is not just limited to the command-V shortcut. If the focus is on the “Insert…” pop-up menu (or another control in the dialog box that is not a text input area) and you press command-A, again instead of ignoring the shortcut Pages ’09 selects the entire contents of the main document window in the background behind the “Find/Replace” dialog box.

So clearly there is a focus problem here. Even though the “Find/Replace” dialog box is very much in the foreground and keyboard shortcuts apply to it and be ignored if they are not relevant, when the focus is on a control that is not a text input area, Pages ’09 wrongly and invisibly switches the focus back to document window in the background.

I believe it’s quite clear that this is the wrong behaviour, even though the “Find/Replace” dialog box is not a modal dialog box and can indeed be left open in the background, with the focus back on the document window. Regardless of this modal flexibility, when the dialog box is in the foreground, keyboard shortcuts should apply to that foreground window exclusively, and be ignored (with a system beep if necessary) if they are not relevant.

It might seem like a minor thing but when, like me, you tend to work fast and try to execute a sequence of keyboard shortcuts in one fell swoop, it’s easy to overshoot. If Pages ’09 behaved properly in this situation, the damage caused by the overshooting would be minimal and easy to undo. Instead, when what I described above happens, you have to switch back to the document window to manually undo what Pages ’09 has just done. And when you repeat the same thing dozens of times during the same day, it can get quite frustrating.

It’s another issue to add to the already long list of issues with Pages ’09’s “Find/Replace” dialog box, as mentioned in my other post earlier this week, which really seems to suggest that Apple’s engineers have not spent much time actually trying to use this dialog box.

I am not about to turn Full Keyboard Access off, because it’s too useful for me. But I also know that I probably will have to live with this problem for a while, because Full Keyboard Access-related issues tend to have a relatively low priority at Apple. (Remember how long it took them to fix iTunes so that it would work properly with Full Keyboard Access.)

If the problem bothers you as much as it bothers me (and even if it does not!), I strongly urge you to submit it to Apple via the Bug Reporter.

When you switch to the “Advanced” tab in the “Find/Replace” dialog box, you have the option to check a box labelled “Match case.” If you check it, then Pages ’09 restricts the search to occurrences that match the exact case of the text string you are looking for.

If you don’t check the option, then Pages ’09 ignores the case in its search for all the occurrences of the text string you are looking for. In other words, a search for “Word” with “Match case” off will find not just occurrences of “Word,” but also occurrences of “word,” “WORD“, “wOrd,” and so on.

The problem in Pages ’09 is with what happens if you try to replace the found occurrences of the text string with a different string or, indeed, with the same string, but with different style options.

Consider the following situation:

I have a Pages ’09 document with various text strings and the “Find/Replace” dialog in the foreground instructing Pages to find occurrences of the first text string without matching the case. In the “Replace:” field, I have the exact same string (with the same case). This is what I would do, for example, if I wanted to apply a specific style to all occurrences of the text string.

Now consider what happens when I click on the “Replace All” button:

What on earth is that about? Pages ’09 has replaced my original string, which only had a capital letter on its first word, with the same string but with a capital letter on every word in the string!

This makes no sense whatsoever. No, I didn’t check the “Match case” option, but that does not mean that I have given Pages ’09 licence to change the case in the found string when replacing it with itself, i.e. with the exact same string (case included)!

In such a situation, with the “Match case” option off, the expected behaviour is that Pages ’09 will find all occurrences of the text string, ignoring the case, and will replace each occurrence with the exact same string, with the same combination of lowercase and uppercase. In other words, if I search for all occurrences of “title with initial capital” with “Match case” off, I expect Pages ’09 to include an occurrence such as “Title with initial capital” in the found occurrences. But if I also put “title with initial capital” in the “Replace:” field, I also expect Pages ’09 to be smart enough to replace “Title with initial capital” with the exact same string, i.e. “Title with initial capital,” and not with “Title With Initial Capital”!

The same problem extends to other lowercase/uppercase combinations. Say I search for “title with word caps” with “Match case” off:

My document includes an occurrence of “Title with Word Caps.” So I expect Pages ’09 to replace that occurrence with the exact same thing. Instead, again it changes the case:

Then I search for “title in all caps” with “Match case” off:

My document includes an occurrence of “TITLE WITH ALL CAPS.” So I expect Pages ’09 to replace that occurrence with the exact same thing. Instead, again it changes the case:

Finally I search for “title in lowercase” with “Match case” off:

My document includes an occurrence of “title in lowercase.” So I expect Pages ’09 to replace that occurrence with the exact same thing… And it does. Phew!

In other words, the only time that Pages ’09 works as expected here is if the found text is all in lowercase. Otherwise, Pages ’09 arbitrarily changes the case of the found string when replacing it in itself.

This effectively makes Pages ’09’s Find/Replace feature useless for batch application of style formatting options to text strings in Pages documents. And it makes it highly unreliable for any find/replace operation if you are not using the “Match case” option.

If you combine this problem with the on-going difficulties that Pages ’09’s Find/Replace has when dealing with curly quotation marks and apostrophes, and with serious bugs such as the one described in yesterday’s post, and with Pages ’09’s failure to find whole word phrases when using the “Whole words” option, it adds up with a pretty poor and unreliable Find/Replace feature in Pages ’09.

It certainly cannot be used for any serious, professional-level work, especially on large documents, where the destructiveness of this unreliable feature might not be immediately apparent and might require lots of manual mopping up after its use.

Pages ’09 does the right thing and displays a dash across the check box, to indicate a mixed (heterogeneous) selection:

(Needless to say, in this area as in so many others, Microsoft Word tends to fail miserably and to be totally unable to correctly display the formatting status of the mixed selection. In this particular case, Word correctly displays the dash in its modal “Paragraph…” dialog box, but if you add the “Keep With Next” toggle button to one of your toolbars, in order to make the option more accessible, the toggle button has no intermediate state to indicate a mixed selection. And there are multiple other formatting options for which Word fails miserably to display the correct status of a mixed selection: Just select two consecutive paragraphs in two different paragraph styles and check the “Style” section of the Formatting Palette…)

In this situation, in Pages, you can leave the selection as it is, or you can click on the “Keep with following paragraph” check box once to apply the formatting option to both paragraphs (the one that already has it and the one that doesn’t have it yet), or you can click on it twice to remove the formatting option from both paragraphs.

That is the normal, expected behaviour in such a situation.

Unfortunately, there is one area where this fails, and that is with text colour and with the text colour control in Pages ’09’s toolbar.

If you have an heterogeneous selection when it comes to text colour and you bring up the text colour palette, Pages ’09 wrongly indicates that the text colour of the current selection is the text colour of the first portion of the selection. See the following example:

My selection includes both black text and red text, but according to the text colour palette in Pages ’09’s toolbar, the current colour of my selection is black.

It gets worse: If I click on the (already selected) black square in order to indicate that I want to apply the black colour to the entire selection, it fails. The colour of the selection remains unchanged, i.e. a mix of black and red.

There is a way around this, fortunately. You can bring up the colour inspector by clicking on the “Colors” button in the Pages ’09 toolbar. Pages ’09 will still fail to reflect the heterogeneous nature of the current selection and wrongly indicate that the text colour of the selection is black in the colour inspector, but at least when you click on the (already selected) black colour in the inspector, Pages correctly applies black to the entire selection.

In my view, both the colour palette and the colour inspector should reflect the heterogeneous nature of the selection by highlighting both colours in the palette/list of colours (just like Pages highlights both styles in the Styles drawer when you have a selection including two different styles). And the toolbar palette should definitely let me apply black to the entire selection, like the colour inspector does.

It is, of course, a minor detail, and the fact that there is a workaround for the worst aspect of it makes it even less significant as a flaw in the product. Still, we expect a great level of attention to detail in Mac OS X products, and this should eventually get fixed.

Here is the scenario.

Say you have a Pages document containing a paragraph of text in body style, followed by a paragraph of text in heading style, followed by another paragraph of text in body style. And say that, for some reason, you have a trailing space after the period and before the return char at the end of the paragraphs in body text. Here’s what it would look like:

If you only have one or two such trailing spaces, you can delete them manually. But what if you have hundreds of them in your document and want to delete them all? Well, the logical thing to do is to use the “Find/Replace” dialog for this purpose. You can put a space followed by a return character (option-Return) in the “Find:” field, and a return character in the “Replace:” field, and specify that the change should apply to the entire document and affect all paragraphs, regardless of their style. This is what I have done in the dialog below, although it’s hard to see the space before the paragraph mark in the “Find:” field, because it’s just a bit of white space next to the padding on the left edge of the field:

And then you can just hit the “Replace All” button and be done with it, right?

There only one slight problem with this. Here’s what you actually get if you use the “Find/Replace” dialog to fix the trailing spaces before the paragraph marks:

What happened to the style of the second paragraph? Well, it’s simply gone. Why? Because, apparently, in the process of replacing the paragraph mark at the end of the first paragraph preceded by a trailing space with a paragraph mark without the trailing space, Pages’s “Find/Replace” dialog changes the paragraph style of the following paragraph as well!

This is pretty bad. The understanding in all modern processors is that the paragraph style of any given paragraph is “stored” in the paragraph mark at the end of that paragraph. So the paragraph mark at the end of the first paragraph in the example above contains the style of the first paragraph, i.e. the body style. And the paragraph style of the second paragraph (the heading) is stored in the paragraph mark at the end of that second paragraph, and has absolutely nothing to do with the paragraph mark of the first paragraph.

Yet obviously in the process of replacing the paragraph mark at the end of the first paragraph, Pages somehow replaces the style of the following paragraph as well. Ouch.

The bottom line here is that you cannot trust Pages ’09 to do proper batch find/replace operations involving paragraph marks. If you need to clean up trailing spaces, you better do it in some other programs, or, if you have the patience, do it manually in Pages. Not a pretty scene.