Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Advanced text extraction #464

Closed
wants to merge 45 commits into from

Conversation

asabramo
Copy link

The work on this branch takes text extraction to much more advanced levels.
It mainly includes support for:

  • Unicode CMAPs (/ToUnicode and /Differences)
  • Correct line extraction
  • Extract text widths
  • Properly handle nested objects
  • Specific support for the Hebrew language encoding is added. Testing was done on both Hebrew and English documents

These are many changes that I've worked on for a while, I did my best to clean up and order them in the limited time I have to do it.
Note - this is my first time contributing to projects on Github so please let me know if I need to do anything differently.

Assi.Abramovitz@gmail.com added 30 commits October 16, 2018 10:14
Add VSCode and GitEye ignores
Higher numbers represent deeper levels of debug.
dbg(0, 'text') should always print it
dbg(10, 'text') should print only if debugLevel is set to 10 or more
The optional lineCallback argument is called for each line in the
extracted text.
The callback receives a list of line elements, each containing text, x
and y.
Use the BT and Td/TD tags to figure out
the real position of a text element in a document.
TD are relative, but BT resets the position.
This corrects the line detection algorithm
to work on documents like BezeqInt
This works for the BezeqInt document.
Probably need to support other forms of CMAP.

Definitely need to support other forms of encoding - e.g. "differences",
as used in the Amex document.

This code is based on:
https://github.com/mstamy2/PyPDF2/pull/201/commits
This fixes the "Fenix" documents
Only supporting the case where Tm is used to do the same as TD
This fixes the "Fenix"
Slightly generalize the text handling to support the TJ element as well.
This should work when there are no specific glyph positioning.
This solves the case of the Supergaz bill.
CMAP - add support for char based mapping
TJ - fix translation

This enables the Bezeq Phone bills
TODO - this may not support a combination of bfrange and bfchar in the same cmap...

However, this does enable the Pelephone bill format :-)
The electricity bill has some garbage (HTML page) after the EOF marker...
PyPDF allows up to 1K of such garbage so the file is rejected.
Increased it to make it work.
TODO: need a more robust solution, to accept files with more garbage.
One way to do it is to cut that garbage before uploading.
The names of the glyphs seem to be "known" with their unicode mappings.
This commit brings such name mappings from two different github projects
to create a common list.
Then the /Differences array is read and parsed into a CMAP compatible
structure so that the translation works.

This removes the hard coded encoding used for Amex and Mastercard Hebrew
documents.
Added extractFonts and extractImages to the PDF reader class.
This allows extraction of the fonts and images form the
whole PDF in a single command, in a standard way.
Seems that the DIFFERENCES array handling was
specific to the way it appeared in the Amex docs.
Changed it to handle the Supergaz case properly too.
Supergaz fonts are TrueType

Also introduced mergine of cmaps from tounicode and differnces
in order to make the unittest pass.
This way one can iterate over the response without checking for None.
This makes the Hot Mobile bill work
Look for \nend at the end, which could actually be the endobject marker.
This is because in the CellcomTV bill there's
just no endstream marker for some of the streams (CMAPs)
Seems like Tm should be treated as an absolute location
(actually offset from the last location, replacing the previous matrix)

This fixes the CellcomTV bill to read the lines correctly
This fixes the PazGaz parsing.
Still, it seems that Pazgas don't provide
the right name for the newsheqel symbol, and it's identified as {
This is a hack for now, until the line size would be determined properly
So for now, the caller needs to tell the pdf extractor
what Y difference should be considered a line break.
This fixes the BezeqPhone bill
This prevents crashing when parsing the IRS names file.
The T*, " and ' elements were not converted to using the new
handleTextElement function.
This came up when trying to open the IRS NAMES file.
Faking a newline operator when the text is over so that the new line
handler is called also for the last line in the text.
Support ranges of characters in the form:
<0000><0002>[<0032><0033><0034>]

This appears in the GetTaxi receipt
This fixes the Pelephone bill parsing
TODO: how should we decide how many bytes
represent each character in the string?

Fixes GetTaxi after the change to support the Pelephone single byte...
Keep all the lines in a dictionary by Y coordinate
and  run the line callback only at the end (of each page)

This fixes the Pelephone date signature
@Tom-Evers
Copy link

So... I upgraded the extractText() function in #397
Does this conflict with those changes?

@asabramo
Copy link
Author

asabramo commented Nov 8, 2018 via email

@MartinThoma MartinThoma added Large PdfReader The PdfReader component is affected labels Apr 6, 2022
@MartinThoma
Copy link
Member

I like this a lot! I need more time to get into the library / improve tests coverage, but I'm definitely in favor of improving the text extraction!

@MartinThoma
Copy link
Member

Is it ok if I resolve the issues?

@asabramo
Copy link
Author

asabramo commented Apr 9, 2022 via email

@MartinThoma
Copy link
Member

Cool, I understand that. Thank you for the swift answer and the pr! I'll take care of the rest :-)

@MartinThoma MartinThoma added text-extraction workflow-text-extraction From a users perspective, text extraction is the affected feature/workflow and removed text-extraction labels Apr 16, 2022
@MartinThoma MartinThoma mentioned this pull request Jun 4, 2022
@MartinThoma
Copy link
Member

MartinThoma commented Jun 5, 2022

@pubpub-zz The file glyphNamesToUnicode.py seems to be pretty similar to _adobe_glyphs.py. The differences are:

  • _adobe_glyphs.adobe_glyphs vs glyphNamesToUnicode.glyphNamesToUnicode
  • _adobe_glyphs creates the dictionary in one run, whereas glyphNamesToUnicode creates an empty dictionary first and adds the items. I think creating it in one run might be better:
  • "/parenleft": "\u0028", vs glyphNamesToUnicode['parenleft'] = 0x0028 -- note the missing leading backslash and the hex representation vs the unicode symbol representation. I think it's better what we have right now as we can use it directly.
  • ⚠️ _adobe_glyphs has roughly 4,320 symbols whereas glyphNamesToUnicode has roughly 14,680 symbols. I wonder if we need the additional 10,000 symbols. For example, circledot and star are in there which could improve our results for https://arxiv.org/pdf/2201.00151.pdf

MartinThoma added a commit that referenced this pull request Jun 5, 2022
Run
  print({"/" + key: fr"\u{hex(value).upper()[2:]:0>4}" for key, value in sorted(adobe_glyphs.items())})
over the glyphlist from #464

This made use of
Glyph Name Formatted Unicode List - GNFUL
GlyphNameFormatter version 0.28 - git commit: 406
Unicode version: Unicode 10.0.0
Source code: https://github.com/LettError/glyphNameFormatter/tree/c225719
@MartinThoma MartinThoma mentioned this pull request Jun 5, 2022
MartinThoma added a commit that referenced this pull request Jun 5, 2022
Run
  print({"/" + key: fr"\u{hex(value).upper()[2:]:0>4}" for key, value in sorted(adobe_glyphs.items())})
over the glyphlist from #464

This made use of
Glyph Name Formatted Unicode List - GNFUL
GlyphNameFormatter version 0.28 - git commit: 406
Unicode version: Unicode 10.0.0
Source code: https://github.com/LettError/glyphNameFormatter/tree/c225719
MartinThoma added a commit that referenced this pull request Jun 6, 2022
Run
  print({"/" + key: fr"\u{hex(value).upper()[2:]:0>4}" for key, value in sorted(adobe_glyphs.items())})
over the glyphlist from #464

This made use of
Glyph Name Formatted Unicode List - GNFUL
GlyphNameFormatter version 0.28 - git commit: 406
Unicode version: Unicode 10.0.0
Source code: https://github.com/LettError/glyphNameFormatter/tree/c225719

Add circledot and star manually
MartinThoma added a commit that referenced this pull request Jun 6, 2022
The highlight of the 2.1.0 release is the most massive improvement to the
text extraction capabilities of PyPDF2 since 2016 🥳🎊 A very big thank you goes
to [pubpub-zz](https://github.com/pubpub-zz) who took a lot of time and
knowledge about the PDF format to finally get those improvements into PyPDF2.
Thank you 🤗💚

In case the new function causes any issues, you can use `_extract_text_old`
for the old functionality. Please also open a bug ticket in that case.

There were several people who have attempted to bring similar improvements to
PyPDF2. All of those were valuable. The main reason why they didn't get merged
is the big amount of open PRs / issues. pubpub-zz was the most comprehensive
PR which also incorporated the latest changes of PyPDF2 2.0.0.

Thank you to [VictorCarlquist](https://github.com/VictorCarlquist) for #858 and
[asabramo](https://github.com/asabramo) for #464 🤗

New Features (ENH):
-  Massive text extraction improvement (#924). Closed many open issues:
    - Exceptions / missing spaces in extract_text() method (#17) 🕺
      - Whitespace issues in extract_text() (#42) 💃
      - pypdf2 reads the hifenated words in a new line (#246)
    - PyPDF2 failing to read unicode character (#37)
      - Unable to read bullets (#230)
    - ExtractText yields nothing for apparently good PDF (#168) 🎉
    - Encoding issue in extract_text() (#235)
    - extractText() doesn't work on Chinese PDF (#252)
    - encoding error (#260)
    - Trouble with apostophes in names in text "O'Doul" (#384)
    - extract_text works for some PDF files, but not the others (#437)
    - Euro sign not being recognized by extractText (#443)
    - Failed extracting text from French texts (#524)
    - extract_text doesn't extract ligatures correctly (#598)
    - reading spanish text - mark convert issue (#635)
    - Read PDF changed from text to random symbols (#654)
    - .extractText() reads / as 1. (#789)
-  Update glyphlist (#947) - inspired by #464
-  Allow adding PageRange objects (#948)

Bug Fixes (BUG):
-  Delete .python-version file (#944)
-  Compare StreamObject.decoded_self with None (#931)

Robustness (ROB):
-  Fix some conversion errors on non conform PDF (#932)

Documentation (DOC):
-  Elaborate on PDF text extraction difficulties (#939)
-  Add logo (#942)
-  rotate vs Transformation().rotate (#937)
-  Example how to use PyPDF2 with AWS S3 (#938)
-  How to deprecate (#930)
-  Fix typos on robustness page (#935)
-  Remove scripts (pdfcat) from docs (#934)

Developer Experience (DEV):
-  Ignore .python-version file
-  Mark deprecated code with no-cover (#943)
-  Automatically create Github releases from tags (#870)

Testing (TST):
-  Text extraction for non-latin alphabets (#954)
-  Ignore PdfReadWarning in benchmark (#949)
-  writer.remove_text (#946)
-  Add test for Tree and _security (#945)

Code Style (STY):
-  black, isort, Flake8, splitting buildCharMap (#950)

Full Changelog: 2.0.0...2.1.0
@MartinThoma
Copy link
Member

@asabramo We (well, @pubpub-zz deserves all of the credit 😄 ) worked a lot on improving the text extraction capabilities of PyPDF2. I think this PR is no longer necessary.

I'm sorry it took so long. Thank you very much for putting the effort in writing this PR 🤗

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Large PdfReader The PdfReader component is affected workflow-text-extraction From a users perspective, text extraction is the affected feature/workflow
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants