Motivation
PDFium may synthesize characters such as whitespace and line breaks while reconstructing a page's logical text.
PageText::text() already documents that its output includes generated whitespace and newlines, but the corresponding PageChar entries currently do not expose whether a character came from the PDF content itself or was generated by PDFium.
This distinction is useful for geometry-sensitive consumers such as layout analysis, OCR alignment, translation, redaction, and text-to-page mapping. Generated characters should generally not be treated as glyphs backed by actual page content.
Proposed support
Would you be open to binding PDFium's FPDFText_IsGenerated() and exposing that provenance through the safe text API?
PDFium uses three return values for this function:
1: the character was generated0: the character was not generated-1: an error occurred
The safe API should preserve the error case rather than interpreting every non-1 result as false.
Possible interfaces include storing the result on PageChar, or exposing it through another text API. Since PageChar is public, adding a field may be a breaking change for exhaustive struct construction or pattern matching, even before 1.0. I would appreciate guidance on which interface best fits the crate.
Compatibility and testing
If the symbol is added to the current eagerly loaded bindings, it may also raise the minimum compatible PDFium build. That compatibility tradeoff may need to be considered as part of the API design.
The existing tests/fixtures/pdfium/hello_world.pdf fixture appears suitable for coverage because its two text objects are separated by a generated line break.
If this direction fits the crate, I'd be happy to contribute a small, focused implementation and tests.
Motivation
PDFium may synthesize characters such as whitespace and line breaks while reconstructing a page's logical text.
PageText::text()already documents that its output includes generated whitespace and newlines, but the correspondingPageCharentries currently do not expose whether a character came from the PDF content itself or was generated by PDFium.This distinction is useful for geometry-sensitive consumers such as layout analysis, OCR alignment, translation, redaction, and text-to-page mapping. Generated characters should generally not be treated as glyphs backed by actual page content.
Proposed support
Would you be open to binding PDFium's
FPDFText_IsGenerated()and exposing that provenance through the safe text API?PDFium uses three return values for this function:
1: the character was generated0: the character was not generated-1: an error occurredThe safe API should preserve the error case rather than interpreting every non-
1result asfalse.Possible interfaces include storing the result on
PageChar, or exposing it through another text API. SincePageCharis public, adding a field may be a breaking change for exhaustive struct construction or pattern matching, even before 1.0. I would appreciate guidance on which interface best fits the crate.Compatibility and testing
If the symbol is added to the current eagerly loaded bindings, it may also raise the minimum compatible PDFium build. That compatibility tradeoff may need to be considered as part of the API design.
The existing
tests/fixtures/pdfium/hello_world.pdffixture appears suitable for coverage because its two text objects are separated by a generated line break.If this direction fits the crate, I'd be happy to contribute a small, focused implementation and tests.