Allow the propagation of the IFilterProvider passed through classes like XrefStreamParser

[marcelo-ramos-sc]

I’ve run into an issue when reading certain PDF files using .NET Framework 4.8. From my investigation, it appears to be related to checksum validation performed in UglyToad.PdfPig.Filters.FlateFilter.

For some files, checksum validation fails and an exception is thrown. As a workaround, I implemented a custom FlateFilter that internally uses ICSharpCode.SharpZipLib.Zip.Compression.Streams.InflaterInputStream from the SharpZipLib NuGet package. This approach successfully resolves the issue for the files I was previously unable to read.

The remaining problem is that the IFilterProvider I implemented is not consistently propagated to some internal classes. As a result, I currently have to modify the PdfPig source code to ensure it is passed through correctly.

In my opinion, this propagation should be supported by default. When an IFilterProvider is supplied, I would expect PdfPig to consistently use the provided implementation rather than falling back silently to the default options.

For example, in UglyToad.PdfPig.Parser.FileStructure.XrefStreamParser, I had to change the signature of TryReadStreamAtOffset from:

public static XrefStream? TryReadStreamAtOffset(
        FileHeaderOffset fileHeaderOffset,
        long xrefOffset,
        IInputBytes bytes,
        ISeekableTokenScanner scanner,
        ILog log)

to:

public static XrefStream? TryReadStreamAtOffset(
        FileHeaderOffset fileHeaderOffset,
        long xrefOffset,
        IInputBytes bytes,
        ISeekableTokenScanner scanner,
        ILog log, 
        IFilterProvider? filterProvider = null)

I then updated the stream decoding logic as follows:

var decoded = stream.Decode(filterProvider ?? DefaultFilterProvider.Instance).Span;

I made similar changes to other methods as well, propagating the IFilterProvider parameter until reaching the OpenDocument method in UglyToad.PdfPig.Parser.PdfDocumentFactory.

I intentionally kept IFilterProvider optional in these method signatures to avoid introducing breaking changes or requiring widespread updates to existing call sites that reference the modified methods.

Would it be possible to add consistent propagation of IFilterProvider throughout PdfPig in a future release?

[BobLd]

@marcelo-ramos-sc thanks for opening the issue.

Can you share the problematic pdf document? We should aim to fix that in the core pdfpig library.

Regarding the filter provider, ill try to have a look to understand what issue you are facing