Reduce Container Dependencies

[deeplow]

Removes three dependencies:

• sudo - no longer needed
• openjdk-8 - see reasoning here
• PDFtk - explained below

Removing PDFtk dependency (replace w/ pdftoppm)

PDFtk actually isn't needed. It was being used for breaking a PDF into pages but this is something that be replaced by the already present pdftoppm (packaged in poppler-utils). Furthermore, by removing this dependency we contribute to reproducible builds and overall supply chain security because it was obtained from gitlab with no signature verification or version pinning.

The replacement pdftoppm enabled us to do a shortcut:
- before: PDF -> PDF pages -> PNG images -> RGB images
- after: PDF -> PPM images -> RGB images

Note about PPM -> RGB "conversion"

And this last conversion step is trivial since the RGB format we were using is just a PPM file without the metadata at the beginning.

Furthermore, we were using a depth of 8 bits per color channel which is exactly the same depth as the the .ppm file format.

To verify the color accuracy, I compared two samples - one obtained from from .pdf to .ppm (via pdftoppm) and a "true" RGB file via the old process (pdftocairo -png + gm convert input.png -depth 8 rgb:file.rgb). Here's the result (compressed in .png) - left .pdf, center .ppm and right .png:

When we compare the .ppm and the original .rgb file, we can see that they differ is some pixel values. But as can be seen in the picture, these minor differences are of little to no consequence to the final human-readable image.

[deeplow]

The replacement pdftoppm enabled us to do a shortcut:

• before: PDF -> PDF pages -> PNG images -> RGB images
• after: PDF -> PPM images -> RGB images

This is now a bit faster. On my system make test changed from 2m30s to 1m30s!

[deeplow]

I also experimented with replacing pdftocairo to convert .pdf to .png, but that wouldn't be as efficient as converting directly to rgb (.ppm).

[apyrgio]

General comment. I was looking into PyMuPDF, and it would be a perfect tool for our needs. It converts to PPM, has rich info in a Pythonic interface, and can render some of the tools useless.

... but we can't install it on Alpine Linux, at least not easily. That's a shame, but I'd like to explore it in the future.

[deeplow]

I was looking into PyMuPDF, and it would be a perfect tool for our needs.

Nice. We could investigate it more in the future. But apart from the installation issues on alpine linux, it's also not available on ARM macOS (source: README.md).

[deeplow]

Looking a bit further into it, the PYMuPDF's installer introduces supply chain issues (some of which we are trying to mitigate in this commit):

• It calls git clone git://git.ghostscript.com/mupdf.git.
• And it also may attempt to download a .tar.gz from `mupdf.org 😬

But feel free to open an issue about it so we can explore it further. Or reconsider our PDF-related software options in general.

[apyrgio]

Thanks for the dig regarding PyMuPDF. Let's punt this discussion until we look into this code once more.

[deeplow]

Rebased from main and squashed commits.

[deeplow]

There were some unintended side-effects of removing openjdk8 in excell files:

before	after