Form Sets¶

• Die Konfiguration kann mehrere Arten von Formularen (Form Sets) enthalten.
• Jedes Form Set kann von einem anderen abgeleitet werden und nur die abweichenden Angaben enthalten.
• Jedes Form Set besteht aus folgenden Angaben:
  • eine oder mehrere Seiten
  • Feldern
  • Feldübergreifende Validatoren
  • Feldübergreifende Ersetzungen

Formularfelder¶

Folgende Angaben sind für Felder möglich

Tesseract¶

Tesseract ist eine freie Implementierung, die von HP entwickelt wurde und jetzt von Google übernommen wurde.

• Home: https://code.google.com/p/tesseract-ocr/
• Python-Bindings: http://code.google.com/p/python-tesseract/

weitere Links:

• http://isbullsh.it/2012/06/Automatic-tesseract-training/
• http://stackoverflow.com/questions/4763956/performance-issues-using-tesseract-ocr-from-a-python-application
• http://wiki.ubuntuusers.de/OCRFeeder

Order¶

Die Reihenfolge der Validierungen ist eindeutig, es muss nicht zwischen Pre- und Post-Replacements unterschieden werden:

The sequence of the validation is unique. A distinction between prior and subsequent substitution is not required.

1. Field replacements

2. Validation

3. Form set choice

   The form type is chosen for which a minimum of tasks are available.

Validators¶

Methods of the field validators:

• Boolean
• Date
• Integer
• Decimal Numbers
• Regular expression
• Minimalwert
• Maximalwert

Methods for the form validators:

• Sum
• Same date or earlier
• Same date or later

Messages¶

In the messages the reasons for the manual checking should be localizable.

Traceability¶

In a format to be specified more precisely all validations, replacements and manual changes has to be saved. Conventional services should be used for analysis.

Allgemeine Prüfungen¶

Sonderfälle, wie zum Beispiel komplette weiße oder schwarze Images oder OCR-Ergebnisse, die weit außerhalb des “Normalen” liegen, sollten ein extra Event werfen.

Innerhalb eines Belegstapels soll geprüft werden, ob es die gleiche PIC-Nr. mehrmals gibt - das darf auf keinen Fall passieren (kommt aber trotzdem selten vor, zuletzt im Abrechnungsmonat 04/2012). Gibt es eine PIC-Nr. mehrmals, so müssen sicherheitshalber alle Belege mit dieser PIC-Nr. gelöscht werden. Die Prüfung auf doppelte PIC-Nr. wird in nachfolgenden Prozessen über alle Monatsrezepte durchgeführt, je eher ein solcher Fehler auffällt, desto besser. Das Löschen der betroffenen Rezepte muß interaktiv erfolgen.

Für Felder, die nur Text enthalten und sonst nicht weiter überprüft werden, muß es trotzdem eine Prüfung auf gültige Zeichen geben. Für die Felder Name, Straße und Ort sind zum Beispiel die Zeichen :, +, ? und ' nicht zulässig, da diese Zeichen bei der Datenlieferung an die Krankenkassen eine besondere Bedeutung haben (Feldtrenner etc.) und nicht an allen Stellen in der bestehenden Software sichergestellt ist, daß diese Zeichen ordentlich escaped werden.

Feldübergreifende Prüfungen¶

Ersetzungen innerhalb von Feldern¶

• Ersetzen von Werten, z.B. ‘G’ durch ‘6’
• Ersetzen von regulären Ausdrücken

Ersetzungen innerhalb von Formularen¶

• Ersetze Werte eines Feldes durch die Werte eines anderen Feldes

Ersetzung von Formularen¶

• Ersetze den aktuellen Formulartyp durch einen anderen

Configuration¶

The client can be configured so that it can view and edit only tasks with certain classifications.

User Interface¶

Prüfziffernverfahren¶

Paths¶

The following attributes are configurable according to the Uniform Naming Convention (UNC):

Protocol

This may be for instance file: for access to the local file system, but may also set conventions for real database access.

Storage Server

In case of the file: protocol, it may be the identifier of the drive (i.E. drive letter on windows).

Path Components

Path to the data base as specification of the partial component

File name

Calculated name of the data base file

Weitere Informationen¶

• Sphinx documentation
• Sphinx reStructuredText Primer
• collective.recipe.sphinxbuilder
• reStructuredText - Markup Syntax and Parser Component of Docutils

Installation¶

$ brew install python
$ brew install python3 # optional if you are a python3-wheenie
$ brew install qt

$ pip install mercurial

Konfiguration¶

Einträge in der Konfigurationsdatei (~/.hgrc unter Linux/MacOS, %USERPROFILE%\Mercurial.ini unter Windows):

[ui]
username = Vorname Nachname <Vorname@Nachname.de>
ssh = ssh -C

[extensions]
# manage different line endings between Linux/MacOS and Windows
eol =

# show progress bar for various operations
progress =

# hg glog shows a semi-graphic log
graphlog =

# colors the output, for instance of hg diff
color =

# handle large and/or binary files
largefiles =

[largefiles]
# hint: the first large file has to be added by hand with hg add --large filename and hg add --normal filename if it's no large file
minsize = 10
patterns = *.CDB *.RDB *.IBF *.jpg *.jpeg *.JPG *.TIF *.tiff *.bmp *.zip *.bz2 *.gz *.tgz *.bmp *.png *.pdf *.PDF *.ast

Projekt kopieren¶

$ hg clone https://bitbucket.org/pydica/pydica

Weitere Informationen¶

• Mercurial CACertificates

Windows 7 64 Bit¶

1. python-2.7.3.msi installiert (32 Bit)
2. setuptools-0.6c11.win32-py2.7.exe installiert
3. PySide-1.1.0qt474.win32-py2.7.exe installiert
4. $ python get-pip.py
5. $ pip install virtualenv
6. $ hg clone https://hg.veit-schiele.de/private/pydica
7. $ cd pydoca
8. $ virtualenv .
9. $ Scripts\active.bat
10. $ pip install pycparser configobj pytest mock
11. die Verzeichnisse C:\Python27\Lib\site-packages\PySide und C:\Python27\Lib\site-packages\PySide-1.1.0qt474-py2.7.egg-info in das site-packages-Verzeichnis des virtualenv kopiert
12. die Datei tiffcp.exe ins Scripts-Verzeichnis des virtualenv kopiert
13. ausserhalb des virtualenv ausgefuehrt: $ pip uninstall pyside
14. im globalen site-packages noch alles gelöscht, was nach pyside aussieht
15. wieder innerhalb des virtualenv die Umgebungsvariable QT_PLUGIN_PATH auf den Pfad zum Plugin-Verzeichnis des pyside im virtualenv gesetzt
16. jetzt klappen sowohl die Tests als auch der Client-Validator

Mac OS X¶

1. $ brew install qt
2. $ brew install python
3. $ pip install mercurial # do _not_ use the brew version -- wrong !!
4. $ brew install python3
5. $ brew install virtualenv
6. $ virtualenv -p python3
7. $ source bin/activate
8. (pydica) $ wget https://bitbucket.org/pydica/pyside-setup/downloads/PySide-1.1.2-py3.3.egg
9. (pydica) $ easy_install PySide-1.1.2-py3.3.egg
10. (pydica) $ bin/pyside_postinstall.py -install
11. (pydica) $ pip install tiffany pytest six

GUI Design Notizen¶

Das Gui wird mit Qt Designer entworfen, solange dies effizient moeglich ist. Der Einstieg in den Designer ist etwas schwierig; der Designer ist teilweise problematisch zu handhaben.

Die meiste Dokumentation bezieht sich auf C++ - Code, und eine groessere Huerde ist, die Umsetzung in PySide zu finden.

Einen Einstieg bietet zum Beispiel

http://developer.qt.nokia.com/doc/qt-4.8/gettingstartedqt.html

Zum Schreiben kleiner erster Programme eignet sich:

http://zetcode.com/gui/pysidetutorial/firstprograms/

Eine entsprechende PySide-Dokumentation findet man unter

http://developer.qt.nokia.com/wiki/PySideDocumentation/ http://developer.qt.nokia.com/wiki/PySide_Tutorials_by_Experience_Level

Das Wichtigste im Kürze¶

Es gestaltet sich relativ einfach, eine Oberflaeche Zusammenzuklicken.

Layouts:

Schwieriger wird es, wenn sich Widgets aneinander ausrichten sollen. Die groesste Huerde ist das Verstehen der Layouts. Layouts funktionieren nur dann richtig, wenn die Kette von innen nach aussen zusammenhaengt.

Es ist hilfreich, diese Dokument durchzuarbeiten:

http://developer.qt.nokia.com/doc/qt-4.8/designer-layouts.html

Splitter:¶

Es dauert eine Weile, bis man versteht dass Splitter im Designer nicht direkt zu sehen sind. Stattdessen sind sie eine spezielle Art Layout.

Stretch-Faktoren:

Jedes Widget hat einen vertikalen und horizontalen Stretch. Das ist die Gewichtung der Widgets beim Layout. Sehr wichtiger Punkt: innerhalb eines Layouts schnurren widgets mit Stretch Faktor 0 auf das Minimum zusammen, wenn andere mehr als 0 haben.

Tips zu Layouts:¶

Wenn ein Widget in einem uebergeordneten Layout sitzt, sind die von diesem Layout kontrollierten Attribute gesperrt. Auch ist es oft unmoeglich, in diesem Zustand neue Widgets hinzuzufuegen oder deren Anordnung zu aendern.

Dazu gibt es als Kontext-Menue und auch als Tool Button oben “Break Layout”. Nach “Break Layout” kann es passieren, dass die Controls zu einem Punkt zusammenschnurren, das macht aber nichts da die Controls jetzt wieder bewegt werden koennen.

Beachte dass es beliebige Undos gibt. Es ist oft einfacher, eine Reihe von Aenderungen zu wiederholen, als es nachtraeglich zu korrigieren.

Es lohnt sich, etwas fummelid zu erstellende Layouts als Template zu speichern, um einen definierten Anfang zu haben.

Projektstruktur¶

Das GUI soll mit Designer bearbeitbar bleiben, aber im Python/PySide entwickelt werden. Damit der Designer weiterbenutzt werden kann, soll sein Output nicht direkt bearbeitet werden.

Konvention: Der Designer erzeugt name.ui Mit pyside-uic erzeugt man

pyside-uic -x -o name_ui.py name.ui

Man schreibt dann von Hand eine

name.py. (nicht zwingend, empfehlung)

Es gibt verschiedene Möglichkeiten, den Hybrid zu bauen.

Einfach und etwas “hackish”:

Zusätzliche Methoden definieren und an die Ui Klasse dran-definieren. Siehe das letzte Beispiel.

Bei grösseren Sachen:

Klasse ableiten, Methoden überschreiben.

Als einfaches Template kann das Hauptprogramm kopiert werden, welches pyside-uic durch “-x” generiert.

Davor importiert man das generierte Form und leitet ein neues ab.

Um das Zusammenspiel zw. QtDesigner und Python zu vereinfachen, folgender Vorschlag:

Benennung bei allen Widgets veraendern, auf die von Python Bezug genommen wird. Benennung in Englisch. Namen sind small_with_underscore

Widgets die bei der Erzeugung gelöscht werden sollen, haben eine Kennung tmp_ vornedran.

Dieser Punkt ist noch nicht ausgereift. Es scheint leicht zu sein, Strukturen zu kopieren, etwa als kleine Widget-Datei.

Design der dynamischen LineEdits¶

Qt hat bei allen Widgets ein Style-Sheet. Dieses konfiguriert das Aussehen der Widgets total und erlaubt zum Beispiel Ändern der Rahmenfarbe.

Beispiel zum Einstieg:

http://developer.qt.nokia.com/doc/qt-4.8/stylesheet-examples.html

Alles Weitere dazu:

http://developer.qt.nokia.com/doc/qt-4.8/stylesheet.html

Funktionierender Prototyp in PySide:

https://hg.veit-schiele.de/dsz/dsz/file/2407ebb6bf2f/src/designer_test

Neues Markierungsverfahren mit Stylesheets¶

Die Verwendung von Stylesheets ergibt eine bessere Moeglichkeit zur Markierung von einzelnen Widgets:

Jedem Widget kann ein Stylesheet zogeordnet werden. Auch wenn gar kein Style benutzt wird, eroeffnet dies beliebige Parametrisierung ueber Kommentare.

Beispiel eines Stylesheets mit Kommentar:

/* BEGIN tmp_line_input_1 */
QLineEdit {
     border: 2px solid green;
}
QLineEdit:focus {
     border: 2px solid lightgreen ;
        margin: 1px ;
}
QLineEdit:hover {
     border: 2px solid green ;
        margin: 1px ;
}

Zum Parsen dieses Strings greift man ueber das Codeobjekt zu, siehe css_test.py:

css_dict = {}

# find css arguments with a 'BEGIN' comment
for const in Ui_Form.setupUi.im_func.func_code.co_consts:
    if isinstance(const, str) and '/* BEGIN' in const:
        widget_name = const.split()[2]
        css_dict[widget_name] = const

Allgemeiner Tip zum Kommando locate unter Mac OS X:¶

das Aktualisieren der Locate-Datenbank geht so:

sudo /usr/libexec/locate.updatedb

(aus http://superuser.com/questions/109590/whats-the-equivalent-of-linuxs-updatedb-command-for-the-mac)

Über Installation und __main__.py¶

http://sayspy.blogspot.de/2010/03/various-ways-of-distributing-python.html

http://docs.python.org/2/using/cmdline.html#interface-options

http://www.boredomandlaziness.org/2011/03/what-is-python-script.html

Wichtiger Hint zum Bauen von PySide:¶

cmake hat einen Bug in Version 2.8.10.1:

Linking CXX executable shiboken
ld: framework not found QtCore
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [generator/shiboken] Error 1
make[1]: *** [generator/CMakeFiles/shiboken.dir/all] Error 2
make: *** [all] Error 2
error: Error compiling shiboken

Dieser Fehler tritt auf, wenn man mit der aktuellen Version von homebrew arbeitet.

Auf die Lösung bin ich durch folgenden Link von Matthew Brett gestossen:

http://permalink.gmane.org/gmane.comp.programming.tools.cmake.user/44595

Der Fehler kann vermieden werden, wenn man die Version folgendermassen zurücksetzt:

cd /usr/local
brew versions cmake

  2.8.10.1 git checkout b5942ec Library/Formula/cmake.rb
  2.8.9    git checkout 54ff55c Library/Formula/cmake.rb
  2.8.10   git checkout d6d8b3e Library/Formula/cmake.rb
  ...

git checkout 54ff55c Library/Formula/cmake.rb
brew switch cmake 2.8.9

cmake --version

  cmake version 2.8.9

Der Hinweis stammt aus

http://stackoverflow.com/questions/3987683/homebrew-install-specific-version-of-formula

Hinweis mit 5 Steps.

Eine Versionsprüfung wird in meine neue Version des PySide - Installers eingebaut. Dieser Installer wird unter

https://bitbucket.org/pydica/pyside-setup

verfügbar.

Zu installierende Pakete¶

tools zum Testen:

pip install mock pytest

tools zum Parsen:

pip install pycparser

Dabei wird automatisch das phantastische ply Packet von David Beazley mitinstalliert. Um die Beispiele von pycparser auszuprobieren, sollte man dennoch das Quellpaket laden:

http://code.google.com/p/pycparser/

Das Quellpaket enthält auch den Praeprozessor cpp.exe.

Zur Installation von pip siehe

http://www.pip-installer.org/en/latest/installing.html#prerequisites

Noch nicht endgültig entschiede Pakete¶

Lesen der Ini-Dateien geht ganz gut mit dem eingebauten ConfigParser. Eine gute Alternative ist evtl. ConfigObj von Michael Foord.

pip install configobj

Stichworte und Kommentare:¶

• CSS Struktur Abkehr von CSS-Tricks CSS - Modul mit eingebetteter Demo-App die das anzeigt Introspection-Tricks moeglich aber nicht notwendig -> weg damit
• Fields-INI Analyse ist notwendig Verifikation anhand vorhandener Daten - die einzelnen Felder muessen verifizierbar erkannt werden

Update 05.04.12:

Struktur vereinfacht, Reduktion auf zunaechst das Noetigste.

Eingrenzung¶

Die Aufgabenstellung ist implizit schon klar, nicht klar ist der zur Umsetzung notwendige Aufwand. Um einen eindeutigen Einstieg zu haben, zunaechst Reduktion auf Attribute “LEFT, TOP, RIGHT, BOTTOM”. Diese Attribute sind erstmal genug um die Positionen zu finden, und es soll sich verifizieren lassen, dass die Sonderfaelle “0 1 1 0” korrekt aus Datei APO_FSRH.C rekonstruiert werden koennen. Erschwerend kommt hinzu, dass dazwischen ein Koordinaten-Wechsel stattfindet. Seiteneffekt: Die Korrektheit der TIFF-Abmessungen wird dadurch leider wichtig. Anmerkung: Die Messung ab linker unterer Ecke ist typisch durch Tiff entstanden. Offensichtlich wurde APO-FSRH.C bereits vor der Adoption von Tiff konzipiert.

FSEARCH.INI (siehe Ende von README.txt) scheint unklar zu sein bezueglich der Frage, was wofuer wie ausgewertet wird. Es ist unklar, ob die vorhandene Analyse ausreicht, oder ob zur endgueltigen Klaerung eine Quellcodeanalyse notwendig ist.

Ich schlage vor, den eingeschlagenen Heuristik-Weg fortzusetzen, solange die dabei ermittelten Ergebnisse plausibel sind. Sollten dabei Dinge unklar bleiben, schlage ich eine Totalanalyse vor, die aber aufwendig ist. Zunaechst verfolge ich den optimistischen Heuristik-Ansatz.

Update 05.04.12:

Einfache, pragmatische Vorgehensweise

Ziele des Projektplans¶

Generell ist ein totaler Ersatz der existierenden Lösung gewünscht. Gleichzeitig sollen die vorhandenen MA vom Neuansatz ueberzeugt werden. Um moeglichst viel fruehzeitigen Feedback zu erlangen, sollen die ersten Schritte gleichzeitig zu - Extraktion und Validierung der Feldpositionen fuehren - vorhandene Scans mit richtiger Position dargestellt werden - das GUI ansprechend und korrekt die Felder darstellen.

Definition Cursorposition¶

Es gibt einen Cursor, der sich in einem Feld befindet. Das klingt zunaechst trivial, bedeutet aber mehr: Der Cursor ist virtuell, d.h. er befindet sich von der Logik her in einem Feld, um das es gerade geht. Physikalisch bedeutet es aber mehr, weil der Bildschirm gleichzeitig verschiedene Darstellungen besitzt.

• Im linken Fenster wird das aktuelle Feld so exakt wie moeglich durch zarte farbliche Kennzeichnung markiert. Editieren erfolgt dabei nicht. Bei Cursorbewegung wandert diese Markierung entsprechend, und die Darstellung wird geaendert.
• Im rechten Feld erscheint ein Eingabefenster, welches sich relativ nahe an der linken Darstellung orientiert, aber mit realen LineEdit-Controls realisiert ist. Diese Controls erlauben eine Texteingabe und sind der Darstellung im linken Bereich weitgehend, aber nicht zwingend angepasst. Hier wird eine entsprechende Rundung, Vereinfachung und Rasterisierung vorgenommen, sodass ein bestmoeglicher Kompromiss zwischen Darstellung und Eingabemoeglichkeit erzielt wird.

Update 05.04.12:

Zunächst nur eine Cursorposition, siehe Tasten.txt

Vorschlag Arbeitspakete und Zeitschaetzung¶

• CSS-Modul Das bisher gewonnene Qt-Wissen schlaegt sich in einem eigenen CSS-Modul nieder, welches ohne Introspection-Tricks die Formatierung der verschiedenen Feldklassen definiert. CSS in der Applikation wird ignoriert und existiert nur zur Darstellung des Prototypen. Die relevanten Controls werden mit Hilfe der Koordinaten-Information und dem CSS-Modul dynamisch erzeugt.

• INI-Analyse erster Teil Die Ini-Datei wird ausgelesen und fehlende Werte aus APO-FSRH.C ergaenzt. Die Struktur wird zunaechst nur im Speicher erzeugt; solange diese Struktur nicht vollstaendig klar ist, halte ich extra-Dateien fuer verfrueht, zumal der Rechenaufwand gering ist.

• Anzeige der Felder im Original (z.Zt. Links) Die Felder werden durch die ermittelten Feldpositionen im Originalbild markiert, auch zur Validierung und als positives Feedback. Die Markierung ist nur zart und nicht stoerend. Die Anzeige erfolgt nur, wenn sich der Cursor im entsprechenden virtuellen Feld befindet.

• Editieren der Felder als Eingabe (z.Zt. Rechts) Gleichzeitig mit der zarten Felddarstellung (links) erfolgt eine Darstellung aller Felder zum Editieren (rechts), wobei ein Edit-Cursor zwischen den Feldern bewegt wird. Das aktuelle Feld zeigt dabei durch CSS seinen Editier-Zustand durch dass CSS-Modul an. Je nach Tastendruck folgt der Cursor dabei der definierten Reihenfolge. Durch Enter wird eine logisch durch die Felddefinition festgelegte Reihenfolge eingehalten. Durch Cursor-Tasten (Auf/Ab) wird das raeumlich naechstgelegene Feld angesteuert. Durch Mausklich wird ein Feld direkt angewaehlt.

  Anmerkungen 09.04.2012 von Daniel:

  • Die Cursor-Tasten sollten nicht die räumlich naechstgelegenen Felder ansteuern, sondern genau wie Enter das vorhergehende bzw. nachfolgende logische Feld. Was das “räumlich naechstgelegende” Feld ist, waere naemlich erst noch zu definieren ist meiner Ansicht nach nicht so ganz trivial und wird bei uns erst einmal nicht gebraucht.
  • Der Punkt “durch Mausklick wird ein Feld direkt angewaehlt” ist momentan sicherlich recht einfach umzusetzen, wenn dann aber spaeter mal die Logik des Validators ins Spiel kommt, ist die Aufgabe der freien Feldauswahl mit der Maus alles andere als trivial, so zumindest meine bisherigen Erfahrungen auf diesem Gebiet. Die freie Positionierung mit der Maus wird momentan zum Ersetzen des aktuellen Programms bei uns nicht dringend benoetigt.

  Update 05.04.12: Doppelte Reihenfolge weggelassen, siehe Tasten.txt

• Abspeicherung bei Feldwechsel Der Zustand eines Feldes wird bei Feldwechsel grundsaetzlich gespeichert. Alle Aenderungen werden grundsaetzlich in einer Session festgehalten. Ungeklaert ist noch, wie lange Sessions existieren sollen und wie lange sie offengehalten werden. Vorschlag ist erstmal, dass man sich in einem noch zu definierenden Batch befindet, den man irgendwann als beendet “abschliesst”. Gespeichert wird die Arbeit aber auf jeden Fall erst einmal.

  Update 05.04.12: Batch ist durch Daniel definiert, grundsaetzlich eine gescannte Gruppe.

• Wechsel zwischen Dateien Beim Verlassen des logisch letzten Feldes wird die naechste Datei geladen und angezeigt. Dies wird in der Statusanzeige entsprechend kenntlich gemacht. Das Laden und Speichern von Dateien geschieht implizit, der Benutzer “bewegt” sich frei innerhalb eines Batches, das noch zu definieren ist. Vorerst gibt es ein Batch als Menge von Dateien, als einfacher Ansatz.

  Update 05.04.12: Siehe Oben, sowie einfacher Datei-Ansatz, testen ob Cache noetig.

• Lesen von TIFF-Dateien Die zugrundeliegenden Tiff-Dateien sind leider etwas komplexer als erwartet und muessen verarbeitbar gemacht werden. Dazu muessen existierende Tools und Biobliotheken analysiert und auf Verwendbarkeit geprueft werden. Im Zweifelsfalle favorisiere ich den dynamischen Ansatz, also Zugriff ueber ein zu schreibendes tiff-Modul, solange der Rechenaufwand klein ist.

  Update 05.04.12: Benutzen von TiffCP, externer Prozess.

Database Abstraction¶

Databases are widely used. Everybody needs them, nobody likes them, and there will never be a perfect solution.

Instead of trying to solve this, we do an abstract solution by providing a way to describe a particular database by its properties in an unspecified abstract property language.

The goal is to describe the currenty existing simple database scheme with a few properties and to make the existing implementation abstract enough to implement one for a different database system.

As far as this current approach goes, it just tries to describe the relevant properties of the database. This should be re-iterated when we get more examples of databases.

We use a simple, preliminary notation of .INI files.:

[DEFAULTS]
active-db           : RDB/CDB demo
descriptive-section : [concrete APRIL]

[concrete APRIL]
customer            : Stein-Reichwald GmbH
vendor              : Walther GmbH
version             : unknown
dbtype              : RDB/CDB
meta-data           : [database meta-data]

[database meta-data]
type                : RDB/CDB
constraints         : [rdb-constraints]
db-properties       : [rdb-properties]
sys-interface       : [system interface]

[rdb-properties]
sql-like            : no
sql-interface       : no
dbase-like          : yes
dbase-interface     : no
object-like         : no
object-interface    : no

[system interface]
native-os          : windows
access-type        : [rdb-files]
network-layer      : novell netware
network-speed      : [novell-netware-speed]

[rdb-files]
files-per-rdb      : 2
file-path-1        : {ident}.CDB
file-path-2        : 00000001/{ident}.IBF
file-type-1        : rdb-form-batch
file-type-2        ; rdb-image-batch

[novell-netware-speed]
open               : fair
close              : fair
read               : slow
write              : slow

[rdb-form-batch]
batch-size         : varying
batch-header-size  : fixed
batch-layout       : [rdb-forms]

[rdb-image-batch]
batch-size         : varying
batch-header-size  : fixed
batch-layout       : [rdb-images]

[rdb-form]
form-header-size   : fixed
form-header-funcs  : (compute_form_header, compute-form-size)
form-size          : fixed
form-size-compute  : function(...)
form-attribute     : [rdb-form-field]

[rdb-form-field]
field-size         : fixed
field-count        : fixed
field-names        : fixed
field-properties   : [rdb-field-attribute]
field-encodings    : (cp850)

[rdb-field-attribute]
attribute-count    : fixed
attribute-type     : string, int32
attribute-size     : fixed(attribute-name)
encoding           : (cp850)

[rdb-image]
image-header-size  : fixed
image-header-funcs : (compute-image-header, compute-image-size)
image-size         : varying
image-size-compute : function(...)
image-attribute    : [rdb-form-field]
image-format       : fax G3/G4