Open gunnsth opened 5 years ago
@peterwilliams97 PR #256 is expected to get us through the first type: vectorized text. Correct? Does that fully include the paragraph fragments discussed?
Related #287 - Extractor api prepared for v3
We have some PDF full-text search code that is unfortunately in a private repo. The idea behind it is simple.
We keep track of the textMark
s that were used to build each page of text. When we break up the page text in any way, we find the textMark
s that correspond to the selected text and compute the enclosing bounding box. The selected text is defined by its start
and end
offsets in the page text: selected := text[start:end+1]
and we sort the textMarks
by offset so this is just 2 binary searches to find an interval of bounding boxes then taking the minimum of the bounding boxes lower lefts and the maximum of the bounding boxes upper rights over that interval.
This issue is a master issue/epic and can lead to subissues that will be referenced from here.
Proposal
The extractor package will have the capability to extract vectorized text and objects (with position and dimensions).
Goal: Extract a list of graphics objects from each PDF page.
There are three types of graphics objects:
Each of these objects has a
This is not a rendering system but we hope to design it in a way that will allow it to be extended to become a renderer. Initial versions of the renderer could convert the lists of graphics objects to PDF or PostScript pages. This would provide closed-loop tests.
Definitions
text: Text objects and operators. The text operators specify the glyphs to be painted, represented by string objects whose values shall be interpreted as sequences of character codes. A text object encloses a sequence of text operators and associated parameters. (page 237)
Paragraph fragments are the largest substrings in text paragraphs that are rendered contiguously on a PDF page. If a paragraph is split between pages or columns then the parts of the paragraph that appear at the end of the first page / column and the start of the second page / column are paragraph fragments. When a paragraph fits entirely within a single column and page, the entire paragraph is a paragraph fragment.
There are at least three levels of text objects, all of which are composed of lower level (lower numbered in the following list) objects.
Initially we will only concern ourselves with stroked and filled paths and ignore clipping paths
This should include inline images, XObject images, possibly some shadings etc. UniDoc already has a pretty good framework for this.
API ideas
The rendering would be over all graphics objects on a page in the order they occur. This would be driven by a single
processor.AddHandler()
that could be configured to emit any combination of text, shape, and image objects.or rendering context/state rather than doX...
Use cases
Potential use cases that should be possible to base on this implementation:
Going from the primitive contentstream operands to a higher level representation, there is a need to have a connection from the higher level representation to the lower level. For example if removing content, may need to filter on a higher level basis but have a connection down to the primitive operands to actually filter those out.
There may be a cascade/sequence of processing operations, initially on the primitive operands, for example grouping.
It should be clear whether those processes are lossy or lossless, where lossless would mean that they could reproduce the exact same operands as originally and same look. Lossy would mean that some aspect was lost, for example if grouping text together, character spacing/kerning info could be lost.
Preferably all processing would have the capability to be lossless, but it remains to be seen whether that is practical.