FormFix works with form sets, forms, and fields, but it does not have classes that directly represent form sets and fields. Instead, it relies on several "processor" classes for that purpose.
FormModel objects directly correspond to forms. As opposed to the more traditional approach of setting properties of a FormModel object to specify its attributes, you specify the properties whenever a FormModel requests them. Each FormModel has a set of events it will raise whenever it needs some information about a form.
The FormModel events include:
Event | Description |
ReadChecksum | An event for retrieving a checksum for the persistent state of a form. |
ReadDataItem | An event for reading a data item from the persistent storage. |
ReadFormImage | An event for reading a form model image. |
WriteDataItem | An event for writing a data item to the persistent storage. |
IdentificationProcessor objects encapsulate a collection of FormModels which most closely matches the concept of a form set. The IdentificationProcessor also implements the functionality required to identify the FormModel which most closely matches a FormImage in question. It also generates registration information required to align the FormImage with the matching FormModel. This identification occurs without the use of special identification or registration marks. In essence, the IdentificationProcessor serves to both define a collection of forms and to match unknown images against forms in the collection.
FormFix has no class that closely represents a field. Instead, it has a DropOutProcessor object that can create field clips, a FieldTypeClassificationProcessor that can determine the type of text in a field, and an OmrProcessor that can capture information from clips of OMR fields. Location and dimension of a field must be provided to the DropOutProcessor, FieldTypeClassificationProcessor, and OmrProcessor so that they can process the appropriate location of the image.