IMHO there is no need to maintain dual hunspell/OSX spellchecker backends.
There are addon OSX spellcheckers for other languages e.g.
http://www.mitzpettel.com/software/hspell.php
. Writing additional spelling servers is pretty simple so I think
the correct approach would be:
1. Getting OSX spelling/grammar checking support working well.
2. If the need arises, wrapping hunspell as an Apple Spelling service
and provide it as a separate project users can install.
Best regards,
Jeremy
On Tue, Jun 9, 2009 at 5:32 PM, Paul Wicks <pwick...@gmail.com> wrote:
> Crap, sorry to post an incomplete version of this post earlier.
> Accidentally hit send before I finished it. Argh...
>
> Anyway,
>
> I've been looking at implementing support for the OS X spellchecker on the
> Mac build as part of my SoC project and I thought I'd run some thoughts I
> had today by the list.
>
> For the basic design, both hunspell and the os x spellchecker need to be
> usable, since hunspell supports more languages than OS X does. The public
> interface of the Spellchecker class is fairly small (mainly 2 methods:
> SpellCheckWord, AddWord). It seems that mapping these onto the OS X
> spellchecker shouldn't be too hard. I originally thought to do something
> more elaborate and create seperate spellchecker classes for each platform,
> but then realized that I could do it more simply as follows:
>
> -leave the majority of spellchecker.cc as is. It works and I don't see any
> reason to mess with what works.
> -for SpellCheckWord, change the call to hunspell_->spell(...) to call a
> (new) private method in the SpellChecker class. In this method, add some
> code at the beginning that will check if we are on the mac and if the
> built-in spellchecker supports the current language and if so checks the
> word using it, other wise using hunspell as before. This way, we can leave
> the rest of the code alone and still use the SpellCheckWordIterator to grab
> individual words out of the string. As for getting the suggestions for a
> word, it might make sense to do things a little differently, since there is
> no need to create and manage the char** suggestions variable to pass to
> hunspell, as NSSpellChecker can give us an easy-to-iterate-through NSArray.
> Probably just an #if defined(OS_MACOSX) would suffice here, since the code
> here will be wholly different.
> -for AddWord, their probably isn't as much of a need to abstract the
> hunspell specific code (it's all hunspell code), so just an #if defined(
> OS_MACOSX)+language support check would suffice.
> -The other public methods all deal with language selection and querying,
> which should remain the same, since the OS X spellchecker only supports a
> subset of the languages supported by hunspell. (there may need to be a
> little bit of code to translate between the codes for supported languages so
> that the built-in spellchecker always gets used when it should, but this
> should be a relatively simple matter.
> -The private method IsValidContraction could call the same new private
> method as defined above.
>
> -This way, the public interface stays the same and the mac folks get to use
> their own dictionary.
> -The newly added autocorrection code should work just the same as before,
> as it relies on SpellCheckWord.
> -also, [NSApplication sharedApplication] needs to be called before the the
> built in spellchecker is used. I'm not sure of where the best place to put
> this call is.
>
> The upside to doing it this way is that it should be relatively easy to
> modify the spellchecking code for any one platform without breaking any
> other.
> The main downside that I can see for doing it this way is that for
> languages that are supported by OS X, we will be keeping a hunspell object
> around that we don't need, at least until the language changes to something
> hunspell supports and os x doesn't
>
> There are a few additional features that the OS X spellchecker supports
> that need some discussion.
> 1. Grammar checker: I know I've seen some talk about adding this to
> chromium somewhere. The OS X spellchecker also has support for checking the
> grammar of a string (only in 10.5+), so that is something to keep in mind
> when that stage is reached.
> 2. Spelling Panel: The OS X spellchecker has support for a "Spelling
> Panel". Similar to spellchecking in most word processors, this provides a
> seperate GUI Panel that allows for checking a whole paragraph in one go. The
> main problems here are that this is functionality that is in no way matched
> by the Windows or Linux Builds. Additionally, it would require some way of
> identifying the source of each word, since the spelling panel allows for the
> creation of a list of ignored words, which are unique to a document. In the
> case of chromium, a document would correspond to a given textfield, most
> likely. The NSSpellChecker API provides a function (uniqueSpellDocumentTag)
> to generate tags for this purpose, but a way would have to be found to
> generate and match these tags up, which could be complicated (although I
> admit that I've not spent a lot of time looking at the code that would need
> to be altered to make this aspect of the spelling panel function).
>
> Any thoughts would be great. Thanks,
>
>
> -Paul Wicks
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
