Mail 2.0 and Spell Catcher X
Posted by Pierre Igot in: MailMay 6th, 2005 • 4:44 am
Mac OS X’s Mail application has changed significantly in Tiger (Mac OS X 10.4). Unfortunately, as is often the case, these changes come at the expense of some new incompatibilities.
One such incompatibility is between Mail 2.0 and Spell Catcher X. While most of Spell Catcher X’s features work properly in Mail, there is one significant issue that affects interactive glossary expansions.
For some reason, from time to time, when you use a Spell Catcher X glossary abbreviation in the body of an e-mail message that you are composing in Mail, after you press the space bar, Spell Catcher does replace the glossary abbreviation with its corresponding glossary expansion as expected, but then inserts a carriage return character instead of the expected space character after the expansion.
As far as I can tell, Mail 2.0 is the only application in which this occurs. But it’s rather annoying. I’ve already reported the bug to Apple, and it’ll probably be fixed eventually — but for now we have to live with it, I am afraid.
I should also mention that interactive glossary expansions only work properly in Mail 2.0 if you disable the “Make replacements directly” option in Spell Catcher X. This option is an advanced feature in Spell Catcher X that unfortunately is not supported by Mail 2.0 — whereas it worked just fine in Mail 1.x.
May 6th, 2005 at May 06, 05 | 5:21 pm
I’m quite sure that the “extra carriage return” problem isn’t Spell Catcher X’s doing at all.
There are a number of posts on Apple’s discussion boards that detail a number of line-ending and other editing problems with the message composition view (an editable WebView).
Take a look at this one for starters.
Scary.
May 7th, 2005 at May 07, 05 | 1:58 am
Yikes.
I never meant to imply that the problem was with Spell Catcher. It’s just that Spell Catcher is an application that reveals this problem in Mail. I haven’t experienced Mail adding spurious carriage returns when I am not using Spell Catcher. So in effect it is a problem between Mail and SCX, even though I agree with you that SCX is not to blame :).
I too am still noticing a number of weird problems when composing a message in Mail. (There were tons more during the beta stage.) What is this “editable WebView” thing you are referring to? Are there other Mac OS X applications in Tiger that use the same “engine”?
May 8th, 2005 at May 08, 05 | 11:23 pm
Mail rendering a return as a space… Mmmm, not surprised that it’s turning SCX’s spaces into returns, then :).
Thanks for exploring this further and filing some bug reports… Yours probably have more clout than mine!
May 9th, 2005 at May 09, 05 | 7:27 pm
I’ve figured this out (the space/return thing). I’d call it a bug in Mail (or editable WebView’s in general). Sure hope Apple does as well.
See this post.
May 7th, 2005 at May 07, 05 | 7:26 am
Yep, something’s seriously wrong with the way they are handling (at minimum) return characters.
Try this:
Turn on the Unicode Hex Input keyboard in International/Input Menu, activate it.
A quick tutorial on how it works: hold down option and type 4 hex digits to produce a character. Useful for Unicodes that are hard to find on a “regular” keyboard layout.
So, for example, option-0-0-4-1 will insert an uppercase “A” (41 hex).
Now we want to test what happens when inserting a return (0x000D) – option-0-0-0-D.
Try it in TextEdit. You get the expected return character.
Try it in a Mail message composition window. Whah? Looks like a space to me. Thing is, it’s NOT a space. If you select that character and drag it to the Character Palette’s Character Info image well, it’s indeed a return.
BUT Mail is rendering it as a space.
Things are not right here…not sure how many things, but enough.
OK – editable WebViews. WebViews have been around since Safari was first introduced. It uses them (or some variant) to display web content, as do many other OS X apps. Before Tiger, these weren’t editable – display only.
But in 10.4, these can be edited. It’s not a trivial addition to WebView. It’s a significant and complex one. Not too surprising it’s got bugs, but we’re running into some pretty blatant ones! Mail uses them in the message body of a compose window. I know that Safari uses them to implement support for contenteditable.
See this blog, specifically the last entry with the link to a demo.
Same exact thing happens in this contenteditable demo. So it’s not just Mail. It’s the underlying widget.
Sure hope it gets fixed soon! Off to file some radars shortly…
December 15th, 2005 at Dec 15, 05 | 8:41 pm
[…] [Via Pierre Igot’s Betalogue] Technorati Tags: Apple Mail, Mail.app […]
January 31st, 2006 at Jan 31, 06 | 9:44 am
[…] So when I discovered some strange behaviour in Mail.app that throws Spell Catcher X off balance, I blogged the solution that I found on Betalogue . (If you use Mail.app and Spell Catcher X you should know about this). […]