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 -~----------~----~----~----~------~----~------~--~---
