feat(table): StrategyAuto for one-axis-ruled tables (opt-in; negative benchmark result recorded) - #21
Conversation
The ICDAR 2013 evaluation found 28 of 125 documents where pdftable detected no table at all, and blamed tables ruled on one axis only: "lines" builds cells from INTERSECTING rulings, so a horizontally-ruled table yields none. Measurement confirmed it exactly -- us-017 has 218 horizontal rules and 0 vertical, us-018 226 and 0, us-025 225 and 0, and all of them go from 0 tables to 3-7 with the other axis inferred. StrategyAuto picks per axis: lines where that axis is ruled, text where it is not BUT the other axis is, and lines when neither is. That last branch is the load-bearing one. Falling back to text on an unruled page is what makes a naive lines->text fallback score worse than lines alone -- precision 0.223 against 0.865 -- because prose has word alignment too and the text strategy will report a table for it. Rulings on the other axis are the evidence that a table is actually present; without that evidence Auto declines to guess. It is NOT a default, because the hypothesis it was built to test came back negative and the number is honest about it: lines precision 0.865 recall 0.229 F1 0.362 auto precision 0.797 recall 0.231 F1 0.358 Detection improved as predicted -- documents with no table found drop from 28 to 23, tables detected rise from 306 to 331. The tables it finds there are gridded badly, so quality on the scored set falls from 0.556 to 0.400 once those harder documents enter it, and recall barely moves. That corrects the earlier conclusion. "The bottleneck is detection, not structure" was inferred from precision on the documents lines could already see -- a population self-selected by being fully ruled. On the harder ones structure is weak too: knowing where a table is does not tell you where its columns are. Both are weak on one-axis-ruled layouts, and fixing detection alone converts almost nothing. Shipped anyway because it is correct for its stated case and a caller who knows their corpus is booktabs-ruled gets a real improvement. The negative result is recorded in docs/evaluations so the next person does not re-run the experiment blind.
|
Warning Review limit reached
Next review available in: 23 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (9)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Reviewer's GuideIntroduce a new opt-in table edge detection strategy (StrategyAuto) that infers one axis from text when the other axis is ruled, wire it into the page edge finder and ICDAR 2013 benchmark harness, and record the (negative) evaluation result with tests that pin behavior and non-default status. Sequence diagram for page.findTableEdges with StrategyAuto resolutionsequenceDiagram
participant Page as page
participant Layout as layout
participant Text as text_layer
Page->>Page: findTableEdges(TableSettings)
Page->>Page: resolveAuto(VerticalStrategy, Vertical, lineLikeEdges)
Page->>Page: resolveAuto(HorizontalStrategy, Horizontal, lineLikeEdges)
alt vStrategy or hStrategy is StrategyText
Page->>Text: Words(WordOpts)
Text-->>Page: words
end
Page->>Page: baseEdges(vStrategy, Vertical, lineLikeEdges, words, TableSettings)
Page->>Page: baseEdges(hStrategy, Horizontal, lineLikeEdges, words, TableSettings)
Page-->>Layout: edges
Flow diagram for resolveAuto table edge strategy selection per axisflowchart TD
A[StrategyAuto input for axis] --> B{strategy == StrategyAuto?}
B -->|no| C[return strategy]
B -->|yes| D{edges on this axis >= minEdgesForAxis?}
D -->|yes| E[return StrategyLines]
D -->|no| F{edges on other axis >= minEdgesForAxis?}
F -->|yes| G[return StrategyText]
F -->|no| H[return StrategyLines - neither axis ruled]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Tests the hypothesis from the ICDAR 2013 evaluation. The hypothesis came back negative. Shipping the feature opt-in and recording why.
Hypothesis
28 of 125 benchmark documents had no table detected at all. Cause confirmed by measurement — every one is ruled on a single axis, and
linesbuilds cells from intersecting rulings:So infer the unruled axis from word alignment. Expectation: recall up, precision holds.
Result — it doesn't work
linesautoRecall moved 0.229 → 0.231. Precision fell. Net slightly worse.
Why — this corrects the earlier conclusion
linesautoDetection improved exactly as predicted. The tables it now finds are gridded badly.
The earlier report said "the bottleneck is detection, not structure", reasoning from precision 0.865 on detected documents. That population was self-selected by being fully ruled. On the hard ones, structure is weak too — knowing where a table is doesn't tell you where its columns are.
Corrected: both are weak on one-axis-ruled tables, and fixing detection alone converts almost nothing.
What's shipped
StrategyAuto, per axis, not a default (TestAutoIsNotTheDefaultpins that). It's correct for its stated case and a caller who knows their corpus is booktabs-ruled gets a real improvement.The conservative rule is load-bearing and stays regardless:
That last branch is why this isn't a naive fallback. Falling back to
texton an unruled page scores 0.223 precision — prose has word alignment too, andtextwill happily report a table for it.Implication for next steps
Don't spend more on heuristics for finding the table. The measurement says the missing piece is row and column structure where rules don't supply it — which is precisely what layout models (Table Transformer et al.) output, as opposed to a bounding box.
Revised hybrid split:
Verification
go build,go vet,go test ./... -count=1 -race— green.docs/evaluations/so it isn't re-run blind.Relates to HAL-568
Summary by Sourcery
Introduce an opt-in StrategyAuto for table edge detection on one-axis-ruled pages, wire it into the table-finding pipeline and ICDAR 2013 benchmark harness, and record the negative evaluation result in docs while ensuring defaults and strategy support remain unchanged.
New Features:
Enhancements:
Documentation:
Tests: