Adding tests for rect extractions #36
Conversation
|
The failing test has nothing to do with the test implemenation, the test is missing a required executable! This seems to be a feature of the visual debug. A hint in the doc would help. |
|
Thanks a lot for your PR, I really appreciate new tests for the library. I cannot push to your branch as the fork is created on your organization, not on your personal account. |
| @@ -31,6 +31,11 @@ | |||
| # test PDFs from official python documentation | |||
| PDF_PYTHON_LOGGING = os.path.join(os.path.dirname(__file__), "pdf", "howto-logging.pdf") | |||
|
|
|||
| # test PDF for rect extraction generateby by sphinx-simplepdf | |||
There was a problem hiding this comment.
| # test PDF for rect extraction generateby by sphinx-simplepdf | |
| # test PDF for rect extraction generated by sphinx-simplepdf |
There was a problem hiding this comment.
Not urgent, but why not fix it when spotted in a review
tests/test_rects.py
Outdated
| visual_debug_output_dir=tmpdir.join("visual_debug_dir"), | ||
| visual_split_elements=True, |
There was a problem hiding this comment.
these 2 should not be needed if you set visual_debug=False
There was a problem hiding this comment.
Yes, but just want to change visual_debug to True without chanching the later ones.
Could be set by using a variable?
vs_debug = False
visual_debug = vs_debug
visual_split_elements = not vs_debug
visual_debug_output = tmpdir.join("visual_debug_dir") if vs_debug else ""
Or just leave it 😄
There was a problem hiding this comment.
Still don't understand this. Why would you provide fields that have no meaning in this context?
The libpdf run will not populate this directory nor split elements, so why passing the params. Maybe I misunderstand your use case here. 🤔
|
PR #37 fails as expected. I propose to cherry-pick my commits into your branch and fix the mentioned issues from my review. |
|
For the rect count in your PDF, this is how the PDF is made, the header row actually has 3 rectangles while the row is just one. If you zoom in extremely, you also see it, e.g. here in Firefox's pdf.js based reader: |
| @@ -31,6 +31,11 @@ | |||
| # test PDFs from official python documentation | |||
| PDF_PYTHON_LOGGING = os.path.join(os.path.dirname(__file__), "pdf", "howto-logging.pdf") | |||
|
|
|||
| # test PDF for rect extraction generateby by sphinx-simplepdf | |||
There was a problem hiding this comment.
Not urgent, but why not fix it when spotted in a review
tests/test_rects.py
Outdated
| visual_debug_output_dir=tmpdir.join("visual_debug_dir"), | ||
| visual_split_elements=True, |
There was a problem hiding this comment.
Still don't understand this. Why would you provide fields that have no meaning in this context?
The libpdf run will not populate this directory nor split elements, so why passing the params. Maybe I misunderstand your use case here. 🤔
|
Added tests for rect extraction for sphinx-simplepdf / weasyprint generated pdf.
Tests checks for textbox extraction from codeblocks, admonitions and tables.
The tests for table did not work as expected. Instead of extracting colored table cells as rect, the 3 table row shown with alternating colors is extracted as whole.
Attached is a picture from visual debug.
The tests now works, asuming the "wrong" number of rects (i would expect 7). See attached file.
All other extractions work like expected.