Most of the groundwork was already there to add a PDF/Page.curve_edges
property. And, inspired, by
https://github.com/jsvine/pdfplumber/discussions/858 and related issues,
we now include 0/90/180/270-degree oriented curve segments into the
default table-detection strategy. As before, you can still switch to the
"lines_strict" to use only lines defined as such (rather than also using
rect and curve edges).
Inspired by https://github.com/jsvine/pdfplumber/discussions/852,
it turns out that .search(...) gets us most of the way, already.
Added a few params (`main_group`, `return_groups`, `return_chars`) to
.search(...) to enable this, which also make that method more generally
flexible.
This commit aims to fix two things:
- The semi-crypticness of the previous version of char_begins_new_word
- The inconsistency (vs. the rest of the approach) in how the method
was comparing "top" to "bottom" for interline comparisons, instead of
"top" to "top", as rightly and helpfully pointed out by @bellma-lilly
in https://github.com/jsvine/pdfplumber/discussions/840
Based on the unit tests, this shouldn't change the output of
`pdfplumber` in the vast majority of use cases. It might affect some
output in edge-cases, for which I apologize for any inconvenience and
which I hope is balanced out by this more consistent approach's benefits
in the long run.
Calculating the bounding boxes of the words is, upon reflection and
testing, not necessary. Instead, all we need is the latest character in
the current word.
With regular expressions, patterns made up entirely of optional groups
(e.g., r"(dfsdgfwerw)?") can return match objects that are, effectively,
empty. These were being treated as real search results, and throwing
errors in the process. Now they're being treated as non-results.
Separately but relatedly, whitespace-only searches were throwing errors.
This was due to (a) how PDFs generally represent whitespace (implicitly,
rather than explicit space characters), and (b) how pdfplumber
internally represents those spaces while performing layout analysis.
This caused search results to have no explicit bounding box, throwing
errors. Now, similarly to handling empty search results, we handle
all-whitespace search results by considering them to be non-results.
Pillow 9.5 throws an error when you try to draw a rectangle where x0>x1
or top>bottom. For rects with small width or height but thick strokes,
we ended up hitting that error because we were trying to subtract the
stroke width from the area to be filled.
Update ag-energy-roundup-curves.ipynb
Update the key name 'point' to 'pts' in the example to the latest version
* 💄
* Update ag-energy-roundup-curves.ipynb
💄
The method belongs to the `PDF` class and not the `Page` class and was in the incorrect section in the README file as pointed out by @sujayvadlakonda
Fixes#834
Any `text_`-prefixed table extraction setting now automatically gets
passed to `.extract_text(...)` via `table.extract(...)`.
This introduces one minor but breaking change, which is that
`keep_blank_chars` (previously, a valid table extraction setting) now
needs to be passed as `text_keep_blank_chars`.
Thanks to @pseudomonas in #798 for flagging.
Decided to go for a stricter approach, given the complexity of getting a
more flexible approach right. But open to PRs that provide the more
flexible approach.
Ritchie Poh