Pages ’09: Still cannot replace straight apostrophes with curly ones

Posted by Pierre Igot in: Pages
January 21st, 2009 • 10:52 am

A while back, I wrote about the fact that it was impossible, in Pages 3.0 (Pages ’08), to use the application’s find/replace feature to find a text string containing a curly apostrophe:

Pages 3.0: Can’t find text string with curly apostrophe

As per usual, at the same time I wrote the blog post, I also submitted a bug report to Apple via Bug Reporter.

Today (16 months later), I finally got a notice that my bug report required my attention, because the developers had responded with a note saying that they believed this issue had “been addressed with the latest version of Pages, part of iLife ’09,” and asking me to confirm that this was the case.

I am used to the very impersonal and much-delayed nature of this communication, of course. That’s the way that Apple operates, and, while it is not exactly convivial, it is obviously still much better than the competition, who don’t ever respond to anything you send them (except to tell you that you are rude and that they are hurt, poor things).

What bothers me, however, is when I observe, after reviewing the issue in the latest version of Pages, that the problem was indeed dealt with, but that it wasn’t fixed properly.

See, in Pages ’08, the problem was simple: if you typed a curly apostrophe in the “Find:” field in Pages’s “Find/Replace” dialog, Pages would completely fail to find any occurrences of the string, even if your document did indeed contain occurrences of the string with the curly apostrophe.

On the contrary, it would actually only find occurrences of the same string with a straight apostrophe. It was quite obviously a bug, and I am glad that Apple did something about it.

But it is very disappointing to observe that they have failed to provide a complete fix for the problem.

In Pages ’09, the situation is now the following. Regardless of whether you type a straight apostrophe, an apostrophe curled to the left or an apostrophe curled to the right in the “Find:” field, Pages will find all occurrences of the apostrophe, including both curly and straight occurrences.

But what is extremely disappointing is that Apple’s engineers appear to have paid no attention whatsoever to the behaviour of the “Replace:” field.

If you put an apostrophe in the “Replace:” field in the “Find/Replace” dialog and then use the “Replace” or “Replace All” button to replace occurrences of the found string with the replacement string, Pages inserts the replacement string… with a straight apostrophe.

This does not make any sense. While the “Find:” field should be (and now is) typographically neutral, the “Replace:” field should not be so!

Why? Imagine the very obvious following scenario: You get a typed text from someone else where all the apostrophes are straight and you want to batch replace them with curly ones.

Try doing that with Pages ’09. It is impossible! You have no option but to do it elsewhere or to do it manually.

Argh.

Now, I immediately went to Bug Reporter and responded to their request to update my bug report. But I know very well what their response is going to be: This is a different bug, so please file a new bug report describing the problem.

And then it’s going to take another 16 months before they do anything about that problem.

Is it really too much to ask that, when such a bug report is submitted, Apple’s engineers investigate the entire issue properly and make sure that all aspects of it are fixed, and not just the one that is clearly outlined in the original bug report?

In other words, is it really too much to ask that Apple’s engineers try to put themselves in the shoes of ordinary users trying to complete ordinary tasks (such as replacing all straight apostrophes in a document with curly ones), especially when a bug report alerts them to a significant flaw in that software in the area in question?

Obviously it is too much, isn’t it?

And so we are in for yet another round of bug reporting and waiting, and waiting, and waiting.

Like I said, it’s better than no response and no bug fix at all—but really there is still lots of room for improvement in this process.


Comments are closed.