ZLIB: Why only decompress/inflate instead of also compress/deflate?

[xD0135]

Why does compress/zlib only provide the ability to decompress/inflate instead of also compress/deflate? I know I could link with zlib directly and make it work but I'm curious to know as to why the core implementation doesn't provide such capability. Thanks

[Kelimion]

It's on my TODO list, as well as a PNG writer and ZIP read/write implementation.

[xD0135]

Thank you for the answer. Any idea on timelines?

[Kelimion]

No hard deadline, but tentatively 2025Q1.

It's part of a rather big set of changes I'm working on, involving the design and implementation of core:archive/zip, compression support for zlib, PNG write support, LZ4 compression and decompression, JPEG read and write, GIF read support, as well as a bit of a redesign of core:compress/* to give it a better core:io compatible streaming interface.

A lot of work, but it'll allow using it for asset packs where you can (for example) use it to load a PNG file from a ZIP archive without having to first unpack the PNG to disk or memory. You'd instead open the ZIP file as a handle and then pass a compressed reader to the PNG loader, or potentially even giving the PNG loader a path like "foo.zip/bar.png" and having it set up the compressed io stream for you transparently.

This then likewise provides the necessary pieces for someone (who's not me) to write a package supporting Office, OpenOffice files, which are effectively ZIP archives with a manifest file and additional data.

In the interim, we have vendor:zlib and vendor:stb for people to write PNG images or otherwise perform Deflate compression.

[xD0135]

Great, thank you!