|< vorhergehende SeiteWillkommennächste Seite >|
Spell Catcher X 10.3 introduces DirectCorrect - an entirely new way to check your spelling. DirectCorrect combines the “write now, check later” capabilities of Check Selection, and the “make an error, fix it now” instant satisfaction of interactive checking.
Without leaving your document, you can instantly check it for errors, see them highlighted, and correct them. In any order you like, when it’s convenient. It’s the ideal way to check and correct short to medium-length documents, perfect for email, instant messaging, web forms and the like.
Spell Catcher’s DirectCorrect feature uses advanced Text Services and Universal Access (accessibility) capabilities that are part of Mac OS X. For the most part, these are the same capabilities used by the Mac OS X Dictionary panel, when looking up a word using the Control-Command-D shortcut. If an application properly supports the Mac OS X Dictionary panel, DirectCorrect should work in that application.
All the built-in Mac OS X text editing views (Cocoa, Carbon and WebKit) support DirectCorrect, so any application that uses a standard Mac OS X editing view will as well. The WASTE 3.0 text editing engine supports DirectCorrect, as well as some 3rd party applications that use their own internal text engine, such as BBEdit and TextWrangler.
DirectCorrect works best when “Enable access for assistive devices” is selected in Universal Access System Preferences. Open Universal Access preferences and make sure this preference is selected.
We’ll use TextEdit, as it has very good support for DirectCorrect. Click here to open TextEdit with a sample document.
NOTE: On Mac OS X 10.5 (Leopard), you may need to move this Help window so it doesn’t obscure the sample document that was opened in TextEdit.
With Spell Catcher selected in the Input menu, choose > Turn DirectCorrect On. You should see something like this:
Errors are highlighted according to kind, using the same colors as Check Selection. Note that DirectCorrect “follows” your document window as you move and resize it, along with its contents whenever it scrolls or is edited. Three controls appear near the top-right of the window, providing the following functionality (from left to right):
The DirectCorrect inspector window should open as well. The inspector displays a live count of what was checked, and the number of errors it found. The controls in the inspector window allow you to change the appearance of highlighted errors, and what part of the document that should be checked. You can also tailor the way that Spell Catcher obtains the positioning, font and style information from the application, in order to get the most accurate results for a particular application or document.
Additional controls are available in the DirectCorrect inspector, click the disclosure button to show or hide them. See below for detailed descriptions of the various DirectCorrect controls.
Most DirectCorrect settings are remembered per-application, saved when you set them while using DirectCorrect with a particular program.
Click a highlighted word to view a list of suggested replacements. Choose a replacement from the list by double=clicking it, or typing the number to its left. Double-clicking a shorthand abbreviation or repeated word error will instantly make the correction using the first suggestion in the list.
The function performed by most controls is generally self-explanatory, but some might warrant a little more explanation. As always, you can hover the mouse over any control in the inspector for a more detailed description.
Choose whether to draw highlights by coloring the words themselves, coloring the background, or underlining the word. The rightmost button hides all highlighted words, but keeps DirectCorrect turned on.
Choose the method used to obtain positioning information from the application.
Choose the method used to obtain font and style information from the application.
Choose how much of the document to check. Visible Text is only available if the application can supply the visible range of characters before DirectCorrect actually checks it and draws the highlighted errors. Selected Paragraphs includes the (entire) paragraphs that enclose the currently selected text.
Choose whether DirectCorrect should remain on (if turned on manually) in all editable text areas.
Select only when the text being checked is laid out in two or more columns. This will increase accuracy, but can significantly impact performance. Always leave deselected for single-column text.
Select to get and display special glyphs/variants for increased accuracy. In some applications, this can cause a significant performance penalty.
The images below illustrate how DirectCorrect highlights text that contains glyph variants, with this preference selected and deselected. It should be obvious which is which.
Select to use Core Text fonts (if available) when using Text Services fonts & styles. (Mac OS X 10.5 only).
The simple answer: Whatever combination you like the most.
The not-so-simple answer: There is no single best combination of settings.
It’s unfortunate that there isn’t a single “best combination” - and the reason DirectCorrect has the number of setting that it does. The reality is that every application behaves differently, with respect to the results given for the positioning, font and style information needed by DirectCorrect. In fact, even within a particular application, the “best” settings can depend on the document you’re editing. So don’t hesitate to try various combinations until you find the ones you prefer.
We have learned a few things about using DirectCorrect with specific applications. You might find our observations useful. Just keep it in mind that software changes - what doesn’t work now might work in the next update. This applies to the Mac OS itself, the applications you use, and last but not least, Spell Catcher X. Email is probably one of the main applications you would want to use DirectCorrect with, so we’ll describe our experiences with Apple’s Mail.
Mail’s message composition window uses WebKit’s HTML editing view. As of this writing, only Text Services are (publicly) supported, as far as obtaining positioning and font information. Unfortunately, WebKit returns an incorrect value, used by DirectCorrect to determine the baseline for drawing highlighted errors. Often, it’s only off by a pixel or two. But there are certain fonts and/or sizes that will give pixel-perfect results. Unfortunately, Mail’s default message font - Helvetica 12, isn’t one of them. Helvetica Neue, however, is. The images below illustrate the difference.
Simply changing Mail’s default message font to one that works better with DirectCorrect may be all you have to do to get the best results.
You may also see positioning problems when using Mail’s stationery - not necessarily because of the font used, but due to the line/paragraph spacing. WebKit reports incorrect positioning when the paragraph spacing is specified in the manner used by most of the stationery samples. This can usually be remedied by deleting the existing paragraph breaks and replacing them by typing a return. This may change the line spacing, but the results get along better with DirectCorrect. A quicker way is to use Spell Catcher’s “Standardize Line Endings” Modify Selection command. Choose to use Unix line endings, and the results will be similar to the images below. Note that the spacing is quite different in this case, whether that is an acceptable compromise is up to you.
There are a number of keyboard shortcuts available when using DirectCorrect that you will likely find useful at times:
Useful when you need to select or otherwise click the highlighted word in the document.
This is useful when you need to click the mouse (to make a selection, for example) in an area of the document that is obscured by a highlighted word.
This is an “emergency escape” mechanism in the unlikely chance that you encounter an application that sometime crashes when DirectCorrect is turned on, and you have selected “Automatically Turn DirectCorrect On in this application” in the DirectCorrect inspector window.
We only encountered a need for this once during development. DirectCorrect was working fine in this particular application, so we selected to Automatically Turn On DirectCorrect. However, when we chose to use Universal Access to obtain positioning information, sometimes the application would crash when asked (a bug in the application’s accessibility support).
DirectCorrect is a feature in its infancy. It uses advanced text input and accessibility technologies that are available to all developers. If one of your favorite applications doesn't have the support required by DirectCorrect, have them get in touch with us. If you find an application that supports DirectCorrect, let us know! If you have ideas or suggestions, contact us at firstname.lastname@example.org.
|< vorhergehende SeiteWillkommennächste Seite >|