It is clearly an uncomfortable liaison: after a period SC misses the first character, but it is there when SC suggests a correction. If you accept the suggestion, it removes the offending bit but doesn't enter the suggestion. So OS X isn't as universal as it claims. Eeenteresting. It also prevents compound characters (eg accents): switch off SC and QM handles them just fine.
QuickMail
Started by Androcles, Jan 08 2004 02:18 PM
1 reply to this topic
#1
Posted 08 January 2004 - 02:18 PM
#2
Posted 08 January 2004 - 11:10 PM
Androcles, on Jan 8 2004, 02:18 PM, said:
It is clearly an uncomfortable liaison: after a period SC misses the first character, but it is there when SC suggests a correction. If you accept the suggestion, it removes the offending bit but doesn't enter the suggestion. So OS X isn't as universal as it claims. Eeenteresting. It also prevents compound characters (eg accents): switch off SC and QM handles them just fine.
But realize that Spell Catcher X is not and cannot ever possibly be as universailly compatible with every app as Spell Catcher 8 was. This is because the underlying OS technology that SCX must use and rely on (input methods and the Text Services Manager) also depends on the application being able to accept text from an input method properly.
This requires the application developer to do at least *some* work on their part, or use standard OS X text editing controls/views/widgets.
One acid test to TRULY see whether an app supports input methods is to see whether it works with the various ones that Apple ships as part of the OS:
Kotoeri (Japanese)
Hangul (Korean)
Simplified Chinese
Tranditional Chinese
Since QuickMail has roots back to OS 8 or even earlier, there's a pretty good chance that the text editing engine it uses isn't a modern, TSM-compatible OS X technology. This is the case with a number of other apps we know of as well.
In fact, there are some apps that are so incredibly poorly-behaved and/or implemented with respect to their text input management that they will not work with any input method (Apple's included) without some sort of re-write. We've even seen some that have their TSM support "half" implemented, which totally screws up every input method. Their programmers have written half the code that's required, and just left out the other half!
It's really very much a two-way street. We can't always be compatible with improperly implemented applications (although sometimes we find ways).
We've implemented a new feature for Spell Catcher X 10.1 to deal with this type of situation - a small "tuner" file (typically 40K or so) that we can specify certain application-specific tweaks. This way we can provide compatibility updates without revising the software itself.
Some compatibility problems are undoubtedly ours, but realize that not all are, and there will always be a handful of applications that we can't possibly every be compatible with because of their (questionable) text handling implementations.
I kind of doubt QuickMail is one of them, this sounds like a typical "tuner" type tweak that is needed.
UPDATE: I found a demo of QM 3.1, and it's not so ancient as I thought. It is, however, apparently a Java app. These have trouble with input methods - well - depending on the version of Java they use. QM doesn't work properly with any of Apple's input methods, but there *may* be a way around it for the next version of Spell Catcher. I also see that the product has changed owners, you might want to ask them what's up with their text input handling.





