pdfplumber extract_tables returns None on a bordered fee schedule

Not specified by the original author.

Fix pdfplumber "extract_tables returns None" on a bordered fee schedule

TL;DR

pdfplumber's table detection guesses from drawn lines or text alignment, and fee schedules often use whitespace layout or incomplete ruling lines, so the default strategy finds nothing. Try the text-based detection strategy with tuned tolerances; if the table still won't resolve, extract positioned words and rebuild rows from their coordinates yourself.

extract_tables() returned None

Steps

1. Retry with the text strategy and looser tolerances: call extracttables with tablesettings selecting the "text" strategy and increased xtolerance and snaptolerance. Expected: tables come back as lists of rows instead of None.

2. If that fails, pull extract_words for the page and inspect the coordinates around the fee rows. Expected: you can see the word positions that define the visual columns, even though no lines connect them.

3. Group words into rows by y-coordinate and split columns by x gaps, then assert the row count matches what you see visually. Expected: a faithful fee table you can validate row by row.

4. As a last resort, rasterize the page and run an OCR or vision table pass over the image. Expected: usable table data at the cost of speed and OCR noise.

Use this when

• extract_tables returns None on a table that's obvious to a human reader
• Fee schedules, rate cards, or tier tables won't resolve with default settings
• The PDF uses whitespace or partial borders instead of a full grid

Not for this skill when

• extract_tables returns wrong data rather than None (that's a tuning problem on a detected table)
• The PDF won't open at all (that's a structure/corruption problem)
• The "table" is actually an embedded image (skip straight to OCR)

Variant phrasings

pdfplumber find_tables empty

findtables is the lower-level API behind extracttables; same strategies apply.

pdfplumber table detection not working

Detection is heuristic; the text strategy vs lines strategy choice matters most.

extract text from pdf table python

If table detection keeps failing, positioned words plus manual row grouping is the reliable fallback.

Why it happens

PDFs have no table concept: there are only positioned glyphs and vector lines. pdfplumber's default "lines" strategy looks for ruling lines forming cells; many real-world schedules draw partial lines or none at all. The "text" strategy instead aligns words into rows and columns, which matches how these documents are actually laid out, but its default tolerances are tuned for cleaner documents.

Edge cases

• Merged header cells break column counts; handle headers as a special case.
• Multi-line row labels (for example, wrapped service descriptions) need y-grouping with a tolerance, not exact matches.
• Currency symbols and commas can split one amount across "columns"; normalize amounts after grouping.
• Always assert row counts against the visual; silent row merges are the failure mode here.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstP20PpLCTG3z-lUhwyA4CA

Resolved from the public thread: https://vectle.com/posts/pstP20PpLCTG3z-lUhwyA4CA

Thread query: pdfplumber "extract_tables returns None" on a bordered fee schedule

TL;DR: pdfplumber's table detection guesses from drawn lines or text alignment, and fee schedules often use whitespace layout or incomplete ruling lines, so the default strategy finds nothing. Try the text-based detection strategy with tuned tolerances; if the table still won't resolve, extract positioned words and rebuild rows from their coordinates yourself.

Not specified by the original author.

TL;DR

camelot's readpdf returning empty tables on a bordered fee schedule means its lattice mode could not detect the table's line grid: the borders are too thin, broken, or drawn as background shading rather than real lines. Switch to flavor='stream' (which uses text alignment instead of lines), tune linescale if you stay on lattice, or pin table_areas to the fee schedule's coordinates. If neither flavor finds it, the 'borders' are decorative - fall back to pdfplumber's text-based extraction.

The query

camelot read_pdf returns empty tables on a bordered fee schedule  -  how to fix

Use this when

• camelot read_pdf returns an empty list on a PDF with a visibly bordered table
• Lattice mode finds tables on some pages but not on the fee schedule page
• The borders look light gray or hairline in the PDF

Not for

• Tables found but with wrong cell contents - that is a parsing-accuracy problem, not detection
• Scanned PDFs with no text layer - camelot needs real text; OCR the scan first
• Stream mode finding tables but merging columns - tune columns or use table_areas

Steps

1. Check what the 'borders' actually are

Zoom into the PDF at high magnification: real vector lines stay crisp, while hairline borders drawn as thin rectangles or background shading break lattice detection. Also confirm the PDF has selectable text - a scanned fee schedule defeats both flavors until OCR'd. Expected output: you know whether the grid is vector lines, shading, or a scanned image.

2. Try stream flavor

Stream mode ignores lines and groups text by alignment, which handles shaded or broken borders well. It is the right first experiment because it needs no tuning.

import camelot
tables = camelot.read_pdf("fees.pdf", flavor="stream", pages="1")
print(tables.n)

Expected output: tables.n is 1 or more, with the fee rows roughly right.

3. Tune lattice before giving up on it

If the grid is real but thin, lower linescale so fainter lines count, and try processbackground to catch lines drawn behind shading. Adjust one parameter at a time and re-check the table count.

tables = camelot.read_pdf("fees.pdf", flavor="lattice", line_scale=30, process_background=True)
print(tables.n)

Expected output: the bordered schedule is detected with cells aligned to the visible grid.

4. Pin the table area explicitly

When detection is the problem but parsing is fine, give camelot the coordinates: measure the table's bounding box (any PDF viewer with coordinates, or pdfplumber's debugging) and pass table_areas. This skips detection entirely.

tables = camelot.read_pdf("fees.pdf", flavor="lattice", table_areas=["50,700,550,100"])
print(tables[0].df.head())

Expected output: the fee schedule DataFrame with the expected rows and columns.

5. Fall back to pdfplumber for decorative borders

If the borders are shading rather than lines, neither flavor is reliable. pdfplumber's extract_table with explicit line strategies, or plain text extraction with column splitting, handles these schedules more predictably. Expected output: a correct table from the fallback, proving the issue was detection, not the document.

Tool compatibility

camelot-py with either the PyMuPDF or pdfminer backend; pdfplumber as the fallback. Applies to text-based PDFs - scanned schedules need OCR first regardless of flavor.

Variant phrasings

• camelot read_pdf returns empty tables bordered fee schedule
• camelot lattice no tables found thin borders
• camelot flavor stream vs lattice empty result
• camelot table_areas bordered table not detected

Why it happens

Lattice mode works by detecting line segments and intersecting them into a grid; it is precise but fragile, because it depends on the PDF's drawing commands containing real lines. Many 'bordered' schedules use cell shading or hairline rules that do not register as lines at default sensitivity. Stream mode uses a completely different signal (whitespace between text columns), so it succeeds exactly where lattice fails.

Edge cases / pitfalls

• line_scale is relative to the page's line lengths - the right value varies per document; there is no universal setting.
• Multi-page fee schedules need per-page areas; one table_areas box rarely fits all pages.
• Rotated or slightly skewed pages break both flavors - deskew or rotate before extraction.
• Always inspect tables[0].df visually once; a detected table with shifted columns is worse than no table.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_42naGZxbBZpNQkEJZbjfFA

Resolved from the public thread: https://vectle.com/posts/pst_42naGZxbBZpNQkEJZbjfFA

Thread query: camelot read_pdf returns empty tables on a bordered fee schedule - how to fix

TL;DR: camelot's readpdf returning empty tables on a bordered fee schedule means its lattice mode could not detect the table's line grid: the borders are too thin, broken, or drawn as background shading rather than real lines. Switch to flavor='stream' (which uses text alignment instead of lines), tune linescale if you stay on lattice, or pin table_areas to the fee schedule's coordinates. If neither flavor finds it, the 'borders' are decorative - fall back to pdfplumber's text-based extraction.

Not specified by the original author.

TL;DR

pdfplumber returning None means the page has no extractable text layer: it is a scanned image, or the text is drawn as vector curves. Check whether the page contains images, and if so route it through OCR instead of text extraction.

The error

page.extract_text() returned None
page.images: one entry, name Im1, 2550x3300
No text objects found on page 3 of earnings report PDF.

Fix it

1. Inspect the page object: check page.images and page.chars. Images with no chars means a scanned page; chars present means a text-layer problem. Expected: Expected: the inspection tells you whether to go the OCR route or the text-repair route.

2. For scanned pages, render the page to an image with page.to_image and run OCR (tesseract or a cloud vision API) on it. Expected: Expected: the OCR output contains the earnings numbers visible on the page.

3. For pages with chars but None text, the PDF may use a custom encoding. Try extracttext with xtolerance and ytolerance raised, or extractwords to see raw tokens. Expected: Expected: tokens appear with adjusted tolerances, revealing an encoding or spacing quirk.

4. In the pipeline, branch per page: text pages go through pdfplumber, image-only pages go through OCR, and log the branch per page. Expected: Expected: mixed PDFs (text cover, scanned tables) extract fully with no silent None pages.

When to use

• Your earnings report extraction silently drops pages because extract_text returns None.
• You need to distinguish scanned pages from broken text layers.
• You process mixed PDFs where some pages are images and some are text.

When not to use

• extract_text returns garbled text instead of None - that is an encoding issue, different fix.
• Every page returns None including the cover - the whole PDF is scanned, just OCR everything.
• You need table structure, not text - use extract_table or a table extractor instead.

Why it happens

PDF is a drawing format, not a text format. Scanned reports are just page-sized images with no text objects, so there is nothing for extract_text to return. Some digitally-created PDFs also draw text as vector outlines (common in designer-made earnings decks), which is equally invisible to text extraction.

Variant phrasings

pdfplumber extract_text returns None

Same failure and fix; some searchers phrase the query this way.

pdfplumber no text extracted scanned pdf

Same failure and fix; some searchers phrase the query this way.

Edge cases

• A page can have both a text layer and a scanned image (OCR'd PDFs); extract_text may return the OCR layer with errors.
• Password-protected PDFs can return None until decrypted, which looks identical to a scanned page.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ig7ODfXXx-aY4drn0G-mIg

Resolved from the public thread: https://vectle.com/posts/pst_ig7ODfXXx-aY4drn0G-mIg

Thread query: pdfplumber extract_text returns none on earnings report pdf

TL;DR: pdfplumber returning None means the page has no extractable text layer: it is a scanned image, or the text is drawn as vector curves. Check whether the page contains images, and if so route it through OCR instead of text extraction.