ROB: Relax flate decoding for too many lookup values

[stefan6419846]

When handling flate objects with a lookup table and the image mode 1, we would previously raise a generic AssertionError if the number of lookup values did not match.

This PR proposes to add a more meaningful error message. Additionally, cases where too many values are specified are now considered a warning only as I could not see any real difference.

I might try to find a document version I can use for public test cases later on to at least cover the case where there are too many values.

[codecov]

Codecov Report

Attention: 4 lines in your changes are missing coverage. Please review.

Comparison is base (8d3f879) 94.37% compared to head (5d3fc66) 94.32%.
Report is 1 commits behind head on main.

Files	Patch %	Lines
pypdf/_xobj_image_helpers.py	50.00%	2 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2331      +/-   ##
==========================================
- Coverage   94.37%   94.32%   -0.05%     
==========================================
  Files          43       43              
  Lines        7660     7666       +6     
  Branches     1515     1518       +3     
==========================================
+ Hits         7229     7231       +2     
- Misses        267      269       +2     
- Partials      164      166       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[stefan6419846]

Example: We have the lookup table b'\x00\x00\x00\xff\xff\xff\n', id est with a trailing whitespace character. This is generated by the SkyPDF Pro Driver for example.

[stefan6419846]

Example document: out1.pdf

[pubpub-zz]

Looks good!
Now we just need to improve test coverage😉

[stefan6419846]

I might have a look at how to emulate the two remaining error cases where we do not have actual example files for now in the next days.

[MartinThoma]

@stefan6419846 Please correct me if I'm wrong, but I don't think it's a bugfix-PR.

A bug in pypdf would mean that pypdf is either...

• ... not acting according to the PDF specification, or
• ... not acting according to the pypdf documentation (directly or indirectly, if the user could get a reasonable expectation for a specific behavior)

This PR has two components:

• ROB: Not raising an exception but just throwing a warning in case of too many values.
• STY: Throwing a more specific error message / different types of error message

As robustness improvements (ROB) are typically more important for pypdf users, I'd start the PR with "ROB".

See https://pypdf.readthedocs.io/en/latest/dev/intro.html (I should probably extend those :-) )

[MartinThoma]

From my side this looks good to be merged 👍 Just let me know if I can change the PR title

[stefan6419846]

@MartinThoma No worries, I am completely fine with you adjusting the title if required, referrring to robustness instead. And adjusting the dev docs sounds like a nice idea as well to make it more clear.

Feel free to merge this PR after updating the title. If I find some time during the next week, I might provide some more test data for the two new edge cases to increase coverage in a separate PR - for now, I just did not stumble upon such files as in theory they violate the PDF standard anyway, while the whitespace stuff seems more spec-like and thus appears in the real world as well.