STY: Add two abbreviations for an inline image object

[j-t-1]

CCF and DCT appended to function decode_stream_data.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.36%. Comparing base (8249981) to head (4f0c026).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3048   +/-   ##
=======================================
  Coverage   96.36%   96.36%           
=======================================
  Files          52       52           
  Lines        8770     8770           
  Branches     1596     1596           
=======================================
  Hits         8451     8451           
  Misses        191      191           
  Partials      128      128           

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

[stefan6419846]

This apparently is not covered by any tests. Are you able to add corresponding ones?

[j-t-1]

Short term maybe not. Could raise as an issue?

[stefan6419846]

We usually have the policy to only merge changes which received proper testing, thus merging it now and adding the tests later is not really the way to go. The easiest solution would be to identify the existing relevant test files and run them through the corresponding test after doing a search-and-replace run for the filter name.

[j-t-1]

Fair. Okay I think you are saying find the tests for CCITT_FAX_DECODE and DCT_DECODE, then find the associated files containing /CCITTFaxDecode and /DCTDecode, and then change these to /CCF and /DCT?

[stefan6419846]

Yes.

[j-t-1]

The abbreviations are mainly (always? I need to read the specification!) for the inline images, but this would work. Ideally the same PDF used for the /CCITTFaxDecode test could have a /CCF in a different stream (same for /DCTDecode and /DCT) to avoid proliferation of files.

[stefan6419846]

We can use the same PDF if we replace the offending specifiers on the fly. Alternatively, we might be able to construct a dummy example to just have an unit test of the corresponding function instead of a full-blown integration test, but both cases require further research/preparation.

[j-t-1]

In filters.py some filters that do not have parameters have a decode_parms argument, for example class ASCIIHexDecode. Removing decode_parms for these classes simplifies them. Thoughts?

[stefan6419846]

No, this should not be removed to have a consistent interface.

[j-t-1]

The consistency of the interfaces is unused. This would be for a future use case?

[stefan6419846]

Not in our code, but its public API, so someone might use it in a way that such a parameter is always passed (although unused internally). To keep it simple and consistent, I am against removing them - regardless of whether they are needed or not.

[j-t-1]

We have the kwargs argument, also unused, and that could serve the same purpose allowing the argument to be passed.

I think the filters code (including _xobj_image_helpers.py) could be simpler.

The docstring of ASCIIHexDecode describes decode_parms but it would be better (if I understand this correctly) to be something like decode_parms: unused; present for interface consistency.

[stefan6419846]

The discussions tend to get more and more out of scope for this PR. Please keep on topic for the actual changes to keep the overview.