Next: GUI wrapper - message
Up: Frontend API
Previous: A simple example
  Contents
  Index
This is under serious review
Although libgocr has several module types, you don't have to use them
all, and is free to abuse of the architecture. In fact, only doing
so you'll be able to take full advantage of libgocr's power.
Let's say, for example, that you are writing an algorithm that skips
the segmentation process, finding characters directly. At first, it
seems that such algorithm would be completely incompatible with libgocr's
structure; but it's not. Here are some possible solutions:
- use the algorithm as a blockFinder module, and do not use any charFinder
or charRecognizer modules. This way you work with the entire image.
- use the algorithm as a charFinder module. It allows the separation
of the image in blocks, and you can treat it block as a whole image.
It's also 100% compatible with other charFinder modules.
You may think that this is an ugly hack, but it's not. I'll
explain why: since the architecture of libgocr is modular, and the
modules can be used independently (with certain exceptions), it's
not only OK to do it, it's designed to be used this way. The module
types had to be given names, but it's as wrong to think that a charFinder
module should only frame characters as to think that charRecognizer
can only recognize usual characters, and not musical notes.
Something else: do not get stuck with gocr_runAllModules().
Since you may change interpretation of module types, it may be interesting
to run them in a different way, skip some, run some twice, allow feedback,
etc.
The question that arises now is: why not make the modules objetcs,
similarly to what is done with block types (see 3.4.1)?
- To do so, the module type objects (MTO) would need to have their own
run() methods. Since some modules use information of their
predecessors (charFinder uses blockFinder, charRecognizer uses charFinder),
MTOs would have to be attached to each other, making a mess.
- There could be an unnecessary multiplication of MTOs. It would be
very easy to decide that ``I don't like that MTO, because the method
names are too big'', and write a new MTO with the same functionality.
- Compatibility. Current module types are 100% compatible with each
other, sharing common structures and variables. Since they are part
of libgocr, you are assured that your module will be compatible with
any other module, something that would not happen with MTOs.
- Current architecture was carefully designed to work well and in a
broad range of situations, and abusing of it is legal.
If you need to create a new module type, it's likely to be a very
specific situation, where you do not care about compatibility.
Next: GUI wrapper - message
Up: Frontend API
Previous: A simple example
  Contents
  Index
root
2002-02-17