Tabular Layout

Can be one of the following values:

The 'TableStyles' enumeration determines how Tabular Layout interprets the physical boundaries of a table within a document. This affects how table rows and columns are detected, how multi-page tables are handled, and how header/footer detection operates.

Choosing the correct value is important for accurate extraction:

Considerations

• The table style impacts how header and footer detection is performed. For Normal tables, headers and footers may appear on different pages. For Floating tables, all content is expected to be on one page.
• If extraction results are missing rows or include unwanted content, review the table style and adjust as needed.
• When in doubt, review sample documents to determine whether the table is page-spanning or region-confined.

The Table Header Detector is responsible for identifying header rows in tabular data during extraction with the Tabular Layout method. It supports multiple header detection strategies, including value extractors, label sets, and column header extractors, to accommodate a wide range of table formats and document layouts.

Header detection is a critical step in tabular extraction, as it establishes the structure and boundaries of the table, enabling accurate mapping of data columns and rows. The detector can handle single-line and multi-line headers, merged or stacked header cells, and variable header positions across pages or table regions.

Configuration Guidance

• Choose a detection strategy that matches your document layout: use a value extractor for pattern-based headers, or leverage label sets for label-driven extraction.
• Adjust the 'Minimum Cell Count' and 'Maximum Line Spacing' properties to fine-tune header recognition for your specific table format.
• Use the 'Repair Threshold' to control how aggressively the detector attempts to fill in missing or incomplete header cells.
• Set 'Run Global' to true if headers are consistent across the entire document, or false to detect headers separately for each table region.

Best Practices

• Test header detection on a variety of sample documents to ensure robust extraction.
• Avoid overlapping or ambiguous header labels, as these can reduce detection accuracy.
• Use diagnostic output to review detected headers and adjust configuration as needed.

For more information, see the documentation for Tabular Layout, Data Table, and Label Set.

The Table Row Detector is a core component of the Tabular Layout extraction method, responsible for identifying and segmenting table rows within a document. It works in conjunction with the Table Header Detector and column configuration to accurately map document content into structured rows and columns.

How Row Detection Works

Row detection operates by analyzing the document's text lines and applying value extractors to locate column values. For a line to be considered a valid table row:

• It must contain values for all columns marked as required in Tabular Layout Options.
• It must meet or exceed the 'Minimum Cell Count' property, ensuring a minimum number of columns are present.
• The horizontal spacing between detected values must not exceed the 'Maximum Gap' property.
• The first row must appear within the distance specified by 'Maximum Header Distance' from the header.

The detector supports a wide range of table layouts, including:

• Tables with variable or missing columns.
• Multi-line rows (when used with Multiline Row Settings).
• Tables split across multiple regions or pages.

Configuration Guidance

• Minimum Cell Count:
  Increase this value to require more columns for a row to be detected, reducing false positives in noisy documents. Decrease for sparse or irregular tables.

• Maximum Gap:
  Adjust to control how far apart column values can be and still be grouped as a single row. Use higher values for wide tables or those with inconsistent spacing.

• Maximum Header Distance:
  Set to allow for extra space or blank lines between the header and the first row. Increase for documents with decorative or whitespace lines after the header.

• Find Column Positions:
  Enable to dynamically adjust header cell boundaries based on detected values, improving alignment in documents with shifting or misaligned columns.

• Merge Multiple Instances:
  Use to combine table regions that are separated by non-row content or page breaks into a single logical table.

Example Scenarios

• Invoice Line Items:
  Detects each line item as a row, even if some columns are occasionally missing (if not required).

• Multi-Page Tables:
  With 'Merge Multiple Instances' enabled, a table that continues across pages will be treated as a single table.

• Tables with Blank Lines:
  Increase 'Maximum Header Distance' to allow for blank or decorative lines between the header and first row.

Troubleshooting & Best Practices

• If extra or partial lines are detected as rows, increase 'Minimum Cell Count' or mark more columns as required.
• If rows are missed due to wide spacing, increase 'Maximum Gap'.
• Use diagnostic output to review which lines are detected as rows and adjust settings accordingly.
• Test with a variety of sample documents to ensure robust extraction across different layouts.

Related Concepts

• Tabular Layout: The extraction method that uses this detector.
• Table Header Detector: Configures header detection for the table.
• Tabular Layout Options: Per-column settings for required columns and detection rules.
• Data Table: The parent object representing the table structure.

For more information, see the documentation for Tabular Layout, Data Table, Table Header Detector, and Tabular Layout Options.

Can be one of the following types:

The Multiline Row Settings class controls how Tabular Layout detects and assembles table rows that span multiple text lines. In many real-world documents, a single logical table row may be split across several lines due to text wrapping, stacked header layouts, or the inclusion of free-form comments and notes.

By configuring these settings, you can ensure that all relevant content is captured for each row, even when it is not confined to a single line.

How Multi-Line Row Detection Works

When enabled, multi-line row detection extends each detected table row to include additional lines that are determined to be part of the same logical row. This is especially useful for:

• Text Wrapping: Cell values that wrap onto subsequent lines.
• Stacked Layouts: Vertically stacked header cells with corresponding stacked values in each row.
• Free-Form Content: Comments, notes, or other information that appears below the main row data.

The detection process uses configurable limits for the number of lines, vertical spacing, and leading lines, and can be further tuned for page-wrapped or stacked layouts.

Configuration Guidance

• Use 'Maximum Lines Per Row' to limit how many lines can be grouped into a single row.
• Set 'Maximum Leading Lines' to allow for lines that precede the main row content, such as descriptions or comments.
• Adjust 'Maximum Line Spacing' to control how much vertical space is allowed between lines in a row.
• Enable 'Detect Page Wrap' to support rows that continue across page breaks.
• Enable 'Detect Stacked Layout' for tables with vertically stacked header and value cells.

Example Scenarios

• Invoice Line Items: Capture item descriptions that wrap onto multiple lines below the main row.
• Stacked Headers: Extract values from rows where each value is stacked vertically under its header.
• Free-Form Notes: Include comments or notes that appear below each row as part of the row's data.

Best Practices

• Test with a variety of sample documents to ensure multi-line detection is robust and does not over- or under-capture content.
• Use diagnostic output to review which lines are grouped into each row.
• Adjust limits and enable/disable features as needed to match your document layout.

For more information, see the documentation for Tabular Layout, Table Row Detector, and Data Table.

Can be one of the following types:

The 'Footer Detection' property allows you to specify a Value Extractor that identifies footer content at the end of a table. This is useful for preventing extraction beyond the intended end of the table, such as when totals, summary lines, or other non-row content appears after the last data row.

When a footer is detected, extraction stops at the line above the footer, ensuring that only valid table rows are included in the output. This helps avoid false positives, such as extra rows being created from summary or notes sections below the table.

• The extractor should match elements that occur at the end of a table, such as total lines or summary text.
• It is not necessary to match the entire line; any text line matched by the extractor will be considered a footer line.
• If the extractor matches multiple lines, only the first such line is considered the footer.

Example

To detect a "Total" line at the end of an invoice table, use a regular expression extractor with a pattern like Total\s*:\s*\d+.

If a footer label is defined in the Label Set, it will take precedence over this property.

The 'Capture Footer Row' property controls whether the detected footer row is included as a data row in the output table. This is useful when the footer contains values you want to extract, such as totals or summary information, rather than serving only as a boundary marker.

• When enabled (true), Grooper will create a final row instance for the table using the detected footer row.
• When disabled (false), the footer row is used only to mark the end of the table and is not included in the output.

Example

Enable this property if your table's footer contains a "Total" row with values you wish to extract as part of the table data.

Compatibility Note:
This property is incompatible with the 'Display Total Row' property. If 'Capture Footer Row' is enabled, you cannot display a computed total row at the bottom of the table using 'Display Total Row'.

Use this property to ensure that important summary or total values in the footer are not missed during extraction.