We need to do some investigation to figure out if it is worth while to share the XP portion of the Spellchecker UI and controller code used by the Netscape 6 Spellchecker. Or just invent some plugin api that allows us to hand off the neccessary document/editor info to a 3rd party spellchecker plugin that is responsible for providing it's own UI. My concern here is that the current Netscape 6 Spellchecker UI and controller code might not be flexible enough for more advanced spellcheckers.
This should actuallly be assigned to me.
moving over to future, setting to enhancement and adding helpwanted
beppe: setting this bug helpwanted is a bit strange, because (as I understand it) no non-Netscape people can work on it! Could you at least make the code available? Or do you just mean the XUL/JS etc. available when you download NS 6? Gerv
there are internal people who also help out
The XUL, JS, and Editor code that drive the spellchecker are all checked into the mozilla tree. The only thing that is missing, is an implementation for nsISpellChecker.h. I gave firstname.lastname@example.org some of the glue code we used for the proprietary spellchecker (with all references to the proprietary code stripped out) so he could see how we did it. If I had my way, I'd redo nsISpellChecker (which is about 2 years old) so that it was a bit more basic.
I'm still working on spell checking and making progress. I hope to have it done soon :)
I couldn't find it anywhere in the FAQ, so I thought I'd ask it here: - Why is the spellchecked closed source? Q3.2 in Mozilla FAQ ("What does Mozilla lack that Communicator has") does not mention spellchecker. - Are there any plans to add an open-source spellchecker to Mozilla (for example, based on an LGPL'ed aspell)?
See bug 56301 - Editor needs spell checking
To answer Aleksey's question ... The underlying spellchecker implementation used by Netscape 6.x and Communicator 4.x was licensed by Netscape from a 3rd party. The source for this spellchecker is *not* open source. When the Netscape 6.x project started, we looked around to see if there were any Open Source spellcheckers that supported *all* the languages that the spellchecker used in Communicator 4.x did, and we didn't find one. So the decision was made to make a spellchecker abstraction and check it into the mozilla src tree, along with it's UI, and keep the nsISpellChecker implementation used in 6.x, which calls into the 3rd party code, private since that is what Netscape is required to do under it's licensing agreement. All that is left to do on the Mozilla.org side of things is to do an nsISpellChecker implementation of *any* OpenSource spellchecker.
I was chatting with Ryan earlier and I proposed a different architecture for spell-checking. Thinking of a multilayered approach where you choose a spell-checker of your choice. Instead of just choosing one checker / one set of dictionaries. What you would need to do then is to add the glue between the Spell-Checking interface and a possibly platform-specific spellchecker. We could then ship a native spell-checker wich Ryan is working on. But have the possiblility to add different ones where available. What do you think of the idea?
> What you would need to do then is to add the glue between the Spell-Checking interface and > a possibly platform-specific spellchecker. > As far as I understand, the idea was to add a pspell-based spellchecker to Mozilla, not some specific spellchecker. Pspell itslef is already a layer of the kind you are describing. Currently, it allows one to use either aspell or (through a pipe) ispell, but according to pspell's author (see attachment 38744 [details] to bug 56301 for an e-mail talking about it) teaching pspell to talk to other spellchecker implementations should be relatively easy. See http://pspell.sourceforge.net/
I'd love to re-architect the way the spellchecker works, but haven't had time to work on it or do much in terms of writing down my thoughts. The short version of what I've been thinking about is this ... The nsISpellChecker interface should be streamlined so that it only contains methods that answer the questions ... "Is this word misspelled." and if so, "What are the list of suggested replacements." Of course this means that the "controller" code that breaks the document up into words, hilites mispelled words and does the actual replacement needs to be handled outside of the spellchecker, which is a good idea anyways. It also means that we'll be able to spellcheck anything, not just a document or text widget. This would also make it much easier for people to write glue code for different spellcheckers, and for us to have them *all* active if we choose.
*** Bug 86886 has been marked as a duplicate of this bug. ***
Have a look at [http://www.wordservices.org/Developers/index.html]. This is the tried- and-tested Word Services architecture used on Mac OS to interface applications in general with third-party services like spelling and grammer checkers and thesauri and such. There's an open RFE for adding it to Mac Mozilla in my bug 67208. Perhaps this consortium can serve as an organizing point for a fully XP effort like this. Their code is free for Mac OS and Be OS at this point.
i'm confused as to why Bugzilla Bug 86886 [RFE] Interface with Apple's spell checker arch on Mac OS X would be a dupe of this bug.
It seems that Word Services should be implemented in pspell rather than being a replacement for pspell.
Hi, my name is Mike Crawford, I led the development of the <a href="http://www.wordservices.org/">Word Services Apple Event Suite</a> when I was working at <a href="http://www.working.com/">Working Software</a>, and later when I was working for them as a consultant, I ported their Spellswell spelling checker to the <a href="http://www.wordservices.org/be">BeOS</a> where it was implemented using BMessages and the BeOS scripting API.<p> An approachable introduction to Word Services on the Mac is in my <a href="http://www.wordservices.org/Developers/mhpaper.html">MacHack '94 paper</a>. The way it's done on the BeOS is <a href="http://www.wordservices.org/Developers/bespec.html">here</a>. The formal Mac OS protocol specification is <a href="http://www.wordservices.org/Developers/Suite/wssuite.html">here</a>.<p> I have been considering for some time how to implement Word Services under *nix. One idea suggested to me (interestingly by Richard Stallman) is to use the CORBA interfaces made available by Gnome widgets. It would make it trivial to implement in gnome applications, but because it would be specified as an interface and not depend explicitly on Gnome, it could be implemented with other frameworks - however, that would require an ORB to be running, which may not be desirable.<p> When I was leading the development of Word Services, I had some discussions with some engineers at WordPerfect (later acquired by Novell, then Corel) about their Writing Tools API. We had a basic agreement to try to harmonize the protocols, and that on windows we would just use the writing tools api. WordPerfect for the Mac implemented Word Services, but it performed poorly. I don't know if they left it in or not. Contrary to Apple's claims, it was quite difficult to add Apple Events to an application that hadn't been originally written to use them. While no single Word Services spellchecker provides all the languages you may want, there are spellcheckers available in a variety of languages, as well as a number of non-spelling text services, such as <a href="http://www02.matsumoto.co.jp/product/jchecker/index_E.html">an HTML verifier</a>.<p> One concern I have I'm sure you have too - that Word Services uses drastically different protocols on different operating systems. This has been necessary because it has been based on the OS-provided API's for accessing the content of user documents, and executing commands in GUI programs. I would very much like for there to be a single, cross-platform way to enable Word Services, that would work the same on all operating systems, but it would need to interoperate with the platform specific standards such as the Apple Object Model.<p> It's best to communicate with me at <a href="mailto:email@example.com">firstname.lastname@example.org</a> - I have a Mozilla account, but haven't been involved in the Mozilla development to date. I have succeeded in building Mozilla from sources the one time I tried, though, and I can develop using Slackware Linux, Debian Power PC, Windows with CodeWarrior, Cygwin gcc or Visual C++, and classic Mac OS with CodeWarrior. I don't yet have a Mac capable of running Mac OS X comfortably.<p>
D'oh! You can see I've never tried to enter a URL into bugzilla before... sorry. I saw hyperlinks elsewhere and thought I could enter HTML here.
For those of you who are not on CC list of bug 56301 - there is now a working implementation of a simple spellchecker attached to that bug.
removing myself from the cc list
Thanks Alexskey. *** This bug has been marked as a duplicate of 180346 ***