Thank you for taking the time and contributing to this project! It's interesting, that the image was just not rendered because it's big. That shouldn't happen and I will investigate it.

As a user I expect that everything is rendered in the quality I supply the artifacts. Microsoft Word or Adobe product also don't compress documents without the users consent. So I think a better enhancement would be, to create another compressed version. I think we should compress the whole document instead of only PNGs.

Compressing PDFs can be easily achieved with ghostscript:

gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook -dNOPAUSE -dQUIET -dBATCH -sOutputFile=output.pdf input.pdf

I'm wondering if that would have actually fixed the issue. I'll try taking the version with the blank images and running gs on it before downloading.

I expect that everything is rendered in the quality I supply the artifacts

I agree. That's why I suggested setting the compression level to 0 and adding a notice in the readme, that blank images may be fixed by changing the compression level.

I wasn't able to run gs for some reason, so I couldn't investigate that further. What I did instead is add a notice that compression is possible in the README and turned it off by default.

I investigated a bit further into optipng, the tool I'm using for the compression. They mention that "OptiPNG is a PNG optimizer that recompresses image files to a smaller size, without losing any information." on their website, meaning that the only downside to using optipng would be a longer CI run. They are using rfc1951, which is based on lz77 and huffman, both lossless compressions.

I expect that everything is rendered in the quality I supply the artifacts

This is still the case, even after running optipng.

Due to making the CI (maybe unnecessarily) longer, I think the correct approach would still be to deactivate it per default, but add a notice in the readme.