typst-pdf: Attach known image types without compression

[krkk]

Most of the image files already have the data compressed, so sprinkling deflate on top of it won't do much besides making it take longer to compile the document.

Initially, #6256 had it right, but then it got flipped during refactoring. I believe it wasn't intentional, hence my PR. :^)
(interesting that clippy doesn't catch equal match cases)

[krkk]

waaaaait this is only for #pdf.attach(), #image() has its own code path. huhhhh, so i guess its almost useless now.
oh well ¯\(ツ)/¯

[saecki]

Most of the image files already have the data compressed, so sprinkling deflate on top of it won't do much besides making it take longer to compile the document.

Initially, #6256 had it right, but then it got flipped during refactoring. I believe it wasn't intentional, hence my PR. :^) (interesting that clippy doesn't catch equal match cases)

Hmm, have you noticed or measured the performance impact of the deflate compression? Because in my testing I've had some cases where images weren't very efficiently encoded and this made quite the difference in size. Note that None in this case means: use automatic compression, and if the threshold isn't met the image is written as is.

[laurmaedje]

Note that None in this case means: use automatic compression, and if the threshold isn't met the image is written as is.

That might be worth a comment, because I also thought it's a typo 😅

[saecki]

Yeah, maybe we can also return a Smart<bool> from should_compress 🤔

[Enivex]

waaaaait this is only for #pdf.attach(), #image() has its own code path. huhhhh, so i guess its almost useless now.
oh well ¯\(ツ)/¯

Relevant #7668

[laurmaedje]

Since this is intentional, let's close this. We could switch to Smart in a separate PR.

Thanks for the PR anyway!