Click here to Skip to main content
13,594,513 members
Click here to Skip to main content
Add your own
alternative version


132 bookmarked
Posted 24 Apr 2005

Document Processing Part II: Request Driven OCR

, 30 Apr 2005
Rate this:
Please Sign up or sign in to vote.
To get qualified access to paper based information, sometimes more than plain OCR is needed. This article shows why, and offers a solution to increase OCR quality by semi-automatic table extraction.

Sample Image - tableextractor.gif


Document processing is used since decades in the financial and insurance industry. In this second part of the overview, the subject is Request Driven Extraction (RDE) as the next step beyond plain OCR analysis.

OCR is a powerful and popular technique to read paper based documents. Today’s OCR systems are no longer restricted to read floating text passages. They also provide higher layout structures like lists and tables. So why do we need extra table extraction?

The Problem

Here is an example: Let’s say, you want to export table data to an Excel file. In our example, you have 3 paper documents with the very same table layout (your phone bills for example). If you are not willing to type in every character manually, you can scan the documents and perform an OCR analysis. But since OCR cannot ‘know’ that all documents contain the same table layout, you will get (worst case) three different table formats.

Tables with plain OCR

A Solution

That is where RDE comes in. With RDE you create a unique table pattern for all documents and let the machine create corresponding results. After the process, you have one single information model for every document - a small but very important difference.

Sample screenshot

The TableExtractor - A User's Manual

To show RDE technology in a simple way, I created the TableExtractor. This application can be seen as an expanded version to the MODI example from Document Processing Part I. Again, MS Office 2003 is required. The new feature is the 'Table Capture Frame'. This is a semi-transparent tool window to customize your personal table requests. The next steps guide you through the whole process of table extraction:

  1. Open an image document.
  2. Press the OCR button to get plain document text.
  3. Select a table you want to extract by using the red selection area.

    Sample screenshot

  4. Press the Adjust button. That will show the Table capture frame. By default, the table request will contain only one single column.
  5. To customize your table request, choose Add Columns and resize them by dragging the column headers.
  6. Press Capture to extract the table.
  7. Export the table result to a file.
  8. Open a new document. Of course, you may use the already customized table.

The TableExtractor – Technical Aspects

The implementation neither includes special tricks nor does it provide breaking new design patterns. I want to draw your attention to the underlying object model.

The Document Model

For the application, we design a simple document model. This is a hierarchy of four layout element classes: Documents, pages, lines, words. We don’t use the MODI Object model this time, because we need the line elements which are not provided in the MODI model. After OCR process is done, we generate an instance of that model by converting the MODI objects. At this point we will not generate lines. That is because of the special character of the cluster algorithm, which clusters words to lines.

The Request Model

In order to represent our knowledge about the table, we create a table request. This table request contains column requests. Each column request provides the relative width referring to the table.

Table Extraction Process

The extraction process is implemented in two simple steps. In the first step, the table’s lines are clustered from the selected word elements. This clustering does a so called Hugh-transformation. Wherever words have overlapping projection on the Y-axis, they are combined to a line element. That’s the reason why we don’t do global line segmentation. Because of noise elements (like OCR errors), Hugh transformations work better when restricted to small areas. The second step iterates through all generated lines and splits the contained words to columns. This is done by using simple intersection criteria.


In this article a very basic table model is described. There are plenty of features to expand this model. Just to give you an idea, I listed a few examples. Please be aware, that some of these points may get very complex and that their development is currently keeping a lot of people busy.

  • Multiple line requests: In our example request model, only one type of line is defined. You may allow alternative line types in one single table.
  • AutoCorrection: You may add data format templates (e.g. regular expressions) to the column request model. That enables you to detect or correct OCR errors in the text content.
  • Column Order: You may expand the model for different column orders and optional columns.


  • 2005-04-25

    Initial version.



This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


About the Author

Martin Welker
CEO Axonic Informationssysteme GmbH, Germany
Germany Germany

You may also be interested in...


Comments and Discussions

GeneralIntegration of this code with third party OCR Pin
ankswe13-Aug-09 17:06
memberankswe13-Aug-09 17:06 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web04 | 2.8.180621.3 | Last Updated 30 Apr 2005
Article Copyright 2005 by Martin Welker
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid