From: Martin Sevior (msevior@physics.unimelb.edu.au)
Date: Sun Sep 22 2002 - 02:07:13 EDT
On Sun, 22 Sep 2002, [iso-8859-1] Andrew Dunbar wrote:
>
> What we probably need to do is start designing a
> grammar checker framework, complete with a plugin
> interface for extensions, and design the barbarism
> checker as a plugin for it.
>
I've discovered that I personally definately need a grammar checker so I'm
happy to help out though not take the lead on a grammar checker.
There are two components. The "squiggling" implementation and the actually
parsing of text.
Regarding the squiggling, we can borrow much of the design from the
spell-checker.
To remind people this works by building a vector of pointers to
fl_BlockLayout classes then processing these during idle time in the GUI
mainloop.
The fl_BlockLayout classes container pointer to text in the piecetable
which is seperated by white space characters into words. These words are
fed through the spell checker.
A grammar check would do exactly the same except it would have to
recognize sentences and parse these through to the grammar checker.
I think we can reuse much of the spell checker code so that
fl_BlockLayouts are parsed through to both the spell checker and the
grammar checker.
If a region of the text is found to be suspect the text is marked with a
green squiggle two pixels below the red squggle.
Hmm the more I think about this, the easier it seems. We can re-use a lot
of the existing classes and methods and just add extra code to split
the text into sentences as well as words.
The grammar checker would have to mark the start and end points of the
dodgy text and send this info back. Then we reuse the squiggle code to
draw between the points.
I think this would not be hard to get working rather quickly.
see the code in the file fl_BlockLayout.cpp
Cheers!
Martin
This archive was generated by hypermail 2.1.4 : Sun Sep 22 2002 - 02:11:52 EDT