Manage table detection

Table detection uses a separate recognition engine and machine learning to automatically locate and identify multiple tables on a document.

Table detection does not support right-to-left languages.

There are three levels of automatic table identification that you can use.

  1. Table detection.

    Table detection is performed without any prior configuration, and it detects all tables in the document automatically. This occurs when the Enable Table Detection setting is enabled for a class. At this point, table data is available in the XDoc only. Because of this, a script is the only way to access the table detection results.

    For more information about scripting and table detection, see the Transformation Designer Scripting Help.

  2. Table classification.

    Table classification identifies the tables that are of interest to the you. This requires sample documents with labeled tables beforehand. Do this by labeling the tables in training documents with an appropriate table model.

    The classification result of a table is available in the XDoc after the Advanced Table Locator is executed. This means that you can also use a script to find a table based on its classification result.

  3. Table and column classification.

    Column classification identifies the columns in the document, and they are mapped to a table model automatically. Do this by labeling each of the columns from the table model of an already labeled table.

    This enables you to use an Advanced Table Locator to extract a table with specific columns from a document.

Levels 2 and 3 above rely on design-time training. No online learning is available for table detection, and no training documents are collected during production. This means that it is necessary to train your project how to use detected table data before releasing your project for production.

A single training document can have multiple table labels. These can be the same table label or a mix of different table labels.

For example, locate and extract the Operating Expense table on an Annual Report. Companies have a legal requirement to provide certain information in their annual reports, such as an Operating Expense table. Even though this is a legal requirement, many of these tables differ between companies in the table name, column names, and layout. The Operating Expense table can have several different table names, such as Operating Expenses, Operating Costs, or Operating Budget, just to name a few. To account for the different table names, add training documents with examples of each different table name and then label those tables with your operating expense table model. The column names on Operating Expense tables can also differ between companies. This means that the same column can be named Current Year, This Year, 2022, etc. To account for different column names it is important to label the individual columns in the already labeled tables with the appropriate column label, so that columns with different column names are identified correctly during production. Once all of the columns and tables are labeled, train your project. When an Operating Expense table is next encountered, it should be correctly identified and extracted.

If your requirements change over time it is necessary to update table detection and retrain your project manually. This is because no training documents are collected during runtime to improve table extraction automatically.

Related topics: