Closed Bug 58615 Opened 24 years ago Closed 22 years ago

Need to investigate sharing the XP portion of the Netscape 6 spellchecker

Categories

(Core :: DOM: Editor, enhancement, P3)

enhancement

Tracking

()

VERIFIED DUPLICATE of bug 180346
Future

People

(Reporter: kinmoz, Assigned: kinmoz)

References

Details

(Keywords: helpwanted)

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.
Cc beppe@netscape.com.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
This should actuallly be assigned to me.
Assignee: beppe → kin
Status: ASSIGNED → NEW
moving over to future, setting to enhancement and adding helpwanted
Severity: normal → enhancement
Keywords: helpwanted
Target Milestone: mozilla0.9 → Future
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 rcassin@supernova.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)?
OS: Windows NT → All
Hardware: PC → All
See bug 56301 - Editor needs spell checking
Blocks: spellchecker
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.
Does this mean that RFE's that ask for an ability to spell-check various things
(namely bug 3459, bug 16409 and bug 23421) should be made dependent on this bug?
*** 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.
Blocks: 67208
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.
Blocks: 69687
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:crawford@goingware.com">crawford@goingware.com</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.
Blocks: 119232
removing myself from the cc list
Thanks Alexskey.

*** This bug has been marked as a duplicate of 180346 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.