In particular, Ben is referring to the automatic spelling correction that Sid is implementing. Off the top of my head, I can think of a few different ways this could fit in:
- We can implement Sid's auto-correction on top of native spellcheck, just like today it's implemented on top of Hunspell. - OS X will provide similar (though not identical) functionality, and we deem this good enough. - We decide native integration is more important than feature parity. As we add more smarts to the spellchecker, we'd need to keep re-evaluating. Thoughts? -Nick On Wed, Jun 10, 2009 at 2:38 PM, Ben Goodger (Google) <b...@chromium.org>wrote: > > For whoever is coordinating this effort, please sync up with Nick Baum > on spell checking. He has some additional considerations in mind we > should make sure we understand what's possible here. > > -Ben > > On Wed, Jun 10, 2009 at 2:36 PM, Mike Pinkerton<pinker...@chromium.org> > wrote: > > > > I think we're all on the same page. I pushed Paul to consider having > > both in his initial design since I forgot about the ability to add > > additional dictionaries. I'm glad others are in support of that as the > > way to get additional language support as opposed to trying to shim > > both implementations together. > > > > I agree with Jeremy, let's focus on the OSX spellchecker and ignore > > hunspell for now. Additionally, let's aim for the OS X spelling dialog > > if we can do it, regardless of whether or not win/linux can do it. > > > > On Wed, Jun 10, 2009 at 11:59 AM, Thomas Van > > Lenten<thoma...@chromium.org> wrote: > >> > >> > >> On Wed, Jun 10, 2009 at 2:38 PM, p_W <paulwoolcoc...@gmail.com> wrote: > >>> > >>> Forgive my (possibly) stupid concern here, but a few months ago there > >>> was some talk about this, and about how integrating with the OS's > >>> spellchecker was the preferred route as it allowed users to use their > >>> dictionary customizations over all their applications. Here is link > >>> to the discussion: > >>> > >>> > >>> > http://groups.google.com/group/chromium-dev/browse_thread/thread/31832b99aeb953d7/d722d0f183a0b35f?hl=en&lnk=gst&q=OSX+spell#d722d0f183a0b35f > >>> > >>> Any thoughts about this? > >> > >> Uh, that's what this thread is about, his project is to switch to using > the > >> os one instead. And Jeremy was commenting that he doesn't need to > support > >> both, just switch to the native. Or am I reading this differently? > >> TVL > >> > >>> > >>> On Jun 9, 9:00 pm, Jeremy Moskovich <jer...@chromium.org> wrote: > >>> > A couple more things: > >>> > > >>> > * I think ultimately we should support the grammar checker, but at > first > >>> > just getting spellchecking to work would be great! > >>> > * +1 for supporting the Cocoa gui for spellchecking paragraphs, see > the > >>> > 2nd > >>> > paragraph bellow for more thoughts on this. > >>> > > >>> > Matching Linux & Windows functionality is a non-goal IMHO, to > reiterate > >>> > we > >>> > want to behave like a native Cocoa application. > >>> > > >>> > WebKit/Safari already support these features so the issue is to get > the > >>> > plumbing working right in our multiprocess model (which may be > >>> > non-trivial). > >>> > IMHO the correct route here is to look at how this is done in WebKit > >>> > and > >>> > match the behavior there as much as possible, that's what I'm doing > with > >>> > the > >>> > keyboard events at the moment and it's proving pretty fruitful. > >>> > > >>> > It's really exciting you're working on this!! > >>> > > >>> > Best regards, > >>> > Jeremy > >>> > > >>> > On Tue, Jun 9, 2009 at 5:50 PM, Jeremy Moskovich > >>> > <jer...@chromium.org>wrote: > >>> > > >>> > > 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 > >>> > >>> > >> > >> > >> > > >> > > > > > > > > -- > > Mike Pinkerton > > Mac Weenie > > pinker...@google.com > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
