How to configure exstruct so 2-row tables (header + 1 row) are detected?

[elfailali]

I’m using exstruct and tuning table detection like this:

set_table_detection_params(table_score_threshold=0, density_min=0.04)

I have very small tables that consist of just a header row plus one data row (2 rows total). These are currently not being recognized as tables.

• Which detection parameters in exstruct control the minimum number of rows / size for a region to be considered a table?
• How can I configure set_table_detection_params (or any other relevant options) so that these small 2-row tables are reliably detected as tables?

[harumiWeb]

Thank you for using exstruct! 🙏

What controls the minimum table size / rows?

set_table_detection_params(...) currently exposes threshold-type knobs (score / density / coverage / min_nonempty_cells), but it does not directly expose min_rows / min_cols.

Before scoring, ExStruct applies a hard plausibility check in _is_plausible_table. In the current implementation, a candidate must satisfy:

• at least 2 rows and 2 columns, and
• at least 2 rows that each have >= 2 non-empty cells, and
• at least 2 columns that each have >= 2 non-empty cells.

Because of this, some small 2-row tables can be rejected even if you set all thresholds to 0.
For example, a 2×2 region with one empty cell like:
[['Library','Content'], [None,'excel automation']]
fails the “>=2 non-empty cells per row/col” condition (only one row and one column have 2 non-empty cells).

Relevant parameters you can tune today

1. min_nonempty_cells

• If the total number of non-empty cells in the candidate region is below this value (default 3), the candidate is discarded early.
• Lowering this helps keep very small regions as candidates.

2. density_min / coverage_min

• A candidate is rejected when both density and coverage are below thresholds.
• Lowering these helps with sparse tables, at the cost of more false positives.

3. table_score_threshold

• Lowering this makes it easier for small tables to pass the final scoring step.

Possible improvement (backward-compatible)

If your use-case requires detecting “sparse” 2-row tables (e.g., 2×2 with one empty cell), we can consider making the plausibility rule configurable (e.g., parameterizing the required non-empty-per-row/col counts) while keeping the current behavior as the default for backward compatibility.

If you can share a minimal example file or a screenshot + cell range, it would help confirm which condition is causing the rejection in your layout.
Thanks again — feedback like this is very useful for improving the heuristic! 🙏

[elfailali]

Thanks for your answer; this is an example of a 1-row table that is not detected:

Is there any solution to avoid the rejection of this type of table?

[harumiWeb]

Thank you for sharing the specific sample.

I'm traveling for about three days starting today, so I can't directly check it here at the moment.
However, looking at the image, it seems the cause is that it's not enclosed by borders.
exstruct's table detection algorithm is based on border patterns, so it cannot detect tables if there are no borders on all four sides.

If you can change the data on your end, setting borders on all four sides of each cell or configuring it as a table will ensure it's recognized.

I will perform a detailed verification on my actual machine environment later, but for now, the immediate answer I can provide is the above.

[harumiWeb]

I recreated and confirmed the Excel sheet you provided on the actual device I have, and I am now convinced that it is being rejected by the table detection algorithm due to the absence of left and right borders.

Currently, exstruct's table detection algorithm is based on border patterns, so it cannot yet detect implicit tables that lack borders and are not considered tables, like the one presented this time. However, we will consider improvements to enhance the table detection algorithm's performance in the future, including the ability to recognize cases like this.