Tabular Layout Options

'Optional' columns participate in row detection, but a row may still be detected if this column is empty. Use this for columns that are helpful for identifying rows but are not always populated. This setting increases flexibility in handling tables with missing or variable data.

'Required' columns must have a value for a row to be detected. This is ideal for key columns that uniquely identify each row, such as an item number or description. Use this to enforce strict row boundaries and prevent false positives in row detection.

'Disabled' columns are excluded from the row detection process. They are treated as secondary columns and are only extracted after row boundaries have been established by other columns. Use this for columns that are frequently empty, contain supplemental information, or require special extraction logic.

'Auto' triggers a secondary extraction only when the primary extraction does not produce a value for the cell. This is the recommended default for most scenarios, balancing performance and reliability.

'Always' forces a secondary extraction attempt for every cell, regardless of whether the primary extraction succeeded. Use this for tables with highly variable or unreliable layouts, but be aware it may increase processing time.

'Never' disables secondary extraction entirely. Use this when the primary extraction method is sufficient and you want to maximize performance or avoid potential data duplication.

The 'Auto' method combines logical and geometric extraction in a two-step fallback sequence:

1. Cell Extract:
   The configured value extractor (such as a pattern match, list match, or custom extractor) is first applied to the text content assigned to the cell by the table extraction engine. Only values matching the extractor's rules are returned.

2. Geometric Fallback:
   If no value is found by the extractor, Grooper then extracts all text physically located within the cell's geometric bounding box (as determined by table layout analysis), regardless of logical cell boundaries or formatting. This text is returned as-is, without further extraction rules applied.

This approach maximizes reliability by first attempting structured extraction, then falling back to a geometric "catch-all" when needed. It is well-suited for tables where most cells are well-formed but occasional merged, spanned, or malformed cells may occur.

Technical Notes:

• The fallback only occurs if the initial extractor returns no value.
• The geometric region may include text from overlapping or adjacent cells if cell borders are unclear.
• No further extraction rules are applied to the geometric fallback text.

The 'Geometric' method extracts all text physically located within the cell's bounding box, as determined by table layout analysis. This includes any text that falls within the cell's region, regardless of logical cell boundaries, formatting, or how the table was parsed.

• No value extractor or pattern matching is applied; the raw text is returned as-is.
• This method is especially useful for tables with merged, spanned, or irregular cells, or when OCR or document formatting causes logical cell parsing to fail.
• It may capture extra or overlapping text from adjacent cells if cell borders are unclear or if the table is poorly structured.

Technical Notes:

• The geometric region is defined by the detected cell borders or layout engine.
• No filtering, parsing, or validation is performed on the extracted text.
• Use this method when you need to recover any visible text in the cell, regardless of structure.

The 'CellExtract' method applies the configured value extractor directly to the text content assigned to the cell by the table extraction engine. Only values matching the extractor's rules (such as regular expressions, value lists, or custom logic) are returned.

• The extraction is limited strictly to the logical cell boundaries as parsed by Grooper.
• No geometric fallback is performed; if the extractor finds no value, the cell remains empty.
• This method is best for cells containing structured or well-formatted data that can be reliably parsed.

Technical Notes:

• The value extractor may be a pattern match, list match, or any custom extractor configured for the column.
• Use this method for columns where each cell contains a single, consistently formatted value (e.g., dates, numbers, codes).
• If the cell contains multiple values or unstructured text, extraction may fail or return incomplete results.

The 'RowExtract' method applies the configured value extractor to the entire concatenated text of the row (all cells combined), rather than just the target cell. This allows extraction of values that may be misaligned, span multiple cells, or appear in unexpected columns due to formatting errors, merged cells, or inconsistent layouts.

• Only values matching the extractor's rules are returned.
• This method is useful for recovering data in tables where values may shift between columns or be distributed across multiple cells.
• It can also help extract multi-cell or multi-line values that do not fit neatly within a single cell.

Technical Notes:

• The entire row's text is concatenated and passed to the value extractor.
• If the extractor is not specific enough, there is a risk of extracting unintended data from other cells in the row.
• Use this method when table structure is highly variable or when other methods fail to locate the desired value.