`getRawTextContent` does not returns words' pieces in proper coordinate order
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 48/100
Research direction
Start by locating getRawTextContent and inspect how bidiTexts items are ordered and how their y coordinates are handled. Reproduce the reported sequence with the example PDF or an equivalent fixture; done means extracted text preserves the intended coordinate order for reversed character groups.
Written by the indexing model from the issue text.
Description
Hey,
getRawTextContent seems to assume that word pieces in the bidiTexts array appear in ascending order of their y coordinate but they probably do appear as they are being added by the PDF rendering software. I have a file where a line of text looking on screen like
Some label 12.3 4455
appears in that array as
Some label | 3 | . | 2 | 1 | 5 | 5 | 4 | 4
that is, the character groups are properly following one after the other but the order of individual characters within the groups is reversed. And getRawTextContent() naively returns
Some label 3.21 5544
The y number of each item correctly shows the correct position but the code is not considering that (it only checks the absolute y difference).
So I wonder if this has a known solution before I go and change the code myself?
Cheers for the nice work.
- Dominant language
- Java
- Stars
- 2.2k
- Forks
- 396
- Avg merge
- 9d 19h
- Merged PRs (30d)
- 3
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from modesty/pdf2json
-
getRawTextContent() returns the lines of every page in reverse order (bottom to top) since 4.0.3Open
Difficulty 1/5 1-3 hours Newbie friendliness 90/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 3/5 1-2 days Newbie friendliness 38/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
help-wanted: type3-font not-supported
Difficulty 4/5 3-5 days Newbie friendliness 42/100
All issues in modesty/pdf2json
Similar issues
-
bug subsystem:agent-harness triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
ShaftHQ/SHAFT_ENGINE#7797 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
NationalSecurityAgency/ghidra#10155 ·
Maintainers usually reply within 2 days
-
area:data coverage
Difficulty 1/5 Under an hour Newbie friendliness 67/100
reacher-z/Awesome-CUA#4864 ·
Maintainers usually reply within 19 days
-
bug web-ui
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
jenkinsci/jenkins#27705 · 3 comments ·
Maintainers usually reply within 1 day
-
mod bug
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
elmital/FixMCStats#65 · 3 comments ·