Problem
RPA.recognition.ocr (and the raw OCR output from RPA.PDF/RPA.Windows/Textract-style integrations) gives back plain text plus word-level bounding boxes and confidence scores. It has no notion of typed values inside that text — a bot author who wants "the date on this line" or "the dollar amount after the label Total:" has to hand-roll regexes and page/line-position bookkeeping every time. This is one of the most common tasks in document-processing bots (invoices, forms, statements) and currently has zero library support.
Idea
Add a small set of composable helpers, roughly:
- Typed matchers:
find_dates(text), find_times(text), find_datetimes(text), find_emails(text), find_amounts(text), find_addresses(text) — each returns match objects with (raw_text, parsed_value, start, end) so callers get both the parsed value (a datetime, Decimal, etc.) and its position in the source text.
- Validators:
is_valid_date(s), is_valid_email(s), is_valid_amount(s) — cheap boolean checks for use in filtering/cleaning extracted table cells.
- Label-anchored search:
find_value_near_label(label, text, matches, same_line=True, next_line=True) — given a field label like "Invoice Date:" and a list of candidate matches (e.g. from find_dates), returns the nearest match that appears after the label on the same line or the following line, handling common delimiters (:, -, whitespace) between label and value.
Potential solution design
- New module:
RPA.recognition.fields (keeps ocr.py focused on raw OCR mechanics, this module focused on text→typed-value extraction; works on any text, not just OCR output, so it's reusable with PDF-extracted text too).
- Matchers implemented as compiled regex patterns per type, refined with a general-purpose date parser (e.g.
python-dateutil, already a lighter dependency than pulling in something heavier) instead of a bespoke date grammar.
- Match result as a small
@dataclass (start, end, raw, value) per type, or a single generic Match dataclass parameterized by value type.
- Label search implemented as: regex-find all label occurrences (word-boundary, case-insensitive) → for each, find nearest candidate match with
start >= label.end() → validate the delimiter substring between them is only whitespace/punctuation → return closest same-line match, falling back to next-line if configured.
- Keep it dependency-light and OCR-engine-agnostic (operates on already-extracted text/positions, doesn't couple to Tesseract vs Textract vs any specific backend).
- Add Robot Framework keywords wrapping the Python API (
Find Dates In Text, Find Value Near Label, etc.) consistent with existing RPA.recognition.ocr keyword style.
Why this belongs in core
This is generic text-to-value extraction, useful independent of which OCR/PDF backend produced the text, and fills a real, recurring gap for document-automation bots rather than adding a one-off integration.
Problem
RPA.recognition.ocr(and the raw OCR output fromRPA.PDF/RPA.Windows/Textract-style integrations) gives back plain text plus word-level bounding boxes and confidence scores. It has no notion of typed values inside that text — a bot author who wants "the date on this line" or "the dollar amount after the labelTotal:" has to hand-roll regexes and page/line-position bookkeeping every time. This is one of the most common tasks in document-processing bots (invoices, forms, statements) and currently has zero library support.Idea
Add a small set of composable helpers, roughly:
find_dates(text),find_times(text),find_datetimes(text),find_emails(text),find_amounts(text),find_addresses(text)— each returns match objects with(raw_text, parsed_value, start, end)so callers get both the parsed value (adatetime,Decimal, etc.) and its position in the source text.is_valid_date(s),is_valid_email(s),is_valid_amount(s)— cheap boolean checks for use in filtering/cleaning extracted table cells.find_value_near_label(label, text, matches, same_line=True, next_line=True)— given a field label like"Invoice Date:"and a list of candidate matches (e.g. fromfind_dates), returns the nearest match that appears after the label on the same line or the following line, handling common delimiters (:,-, whitespace) between label and value.Potential solution design
RPA.recognition.fields(keepsocr.pyfocused on raw OCR mechanics, this module focused on text→typed-value extraction; works on any text, not just OCR output, so it's reusable with PDF-extracted text too).python-dateutil, already a lighter dependency than pulling in something heavier) instead of a bespoke date grammar.@dataclass(start,end,raw,value) per type, or a single genericMatchdataclass parameterized by value type.start >= label.end()→ validate the delimiter substring between them is only whitespace/punctuation → return closest same-line match, falling back to next-line if configured.Find Dates In Text,Find Value Near Label, etc.) consistent with existingRPA.recognition.ocrkeyword style.Why this belongs in core
This is generic text-to-value extraction, useful independent of which OCR/PDF backend produced the text, and fills a real, recurring gap for document-automation bots rather than adding a one-off integration.