On Thu, Mar 28, 2024 at 10:44:41AM -0700, Andre Glover wrote: > The 'canned' compression mode implements a compression scheme that > uses a statically defined set of Huffman tables, but where the Deflate > Block Header is implied rather than stored with the compressed data. This already exists in standard DEFLATE; it's called fixed mode. See section 3.2.6 of RFC1951 (https://datatracker.ietf.org/doc/html/rfc1951#page-12). I think that what's going on is that you've implemented a custom variant of DEFLATE where you set the fixed Huffman codes to something different from the ones defined in the standard. Is that correct, or are there other differences? Actually, looking at your zlib_tr_flush_block(), it looks instead of using the reserved block type value (3) or redefining the meaning of the fixed block type value (1), you actually deleted the BTYPE and BFINAL fields from the data stream entirely. So the stream no longer stores the type of block or the flag that indicates whether the block is the final one or not. That has the property that there cannot be any standard blocks, even uncompressed blocks, included in the data stream anymore. Is that intentional? Maybe this is why you're using the name "canned", instead of going with something more consistent with the existing "fixed" name, like "custom-fixed"? I wonder what the plan is for when the next hardware vendor tries to do this and chooses their own Huffman codes, different from yours. Or what if Intel decides the Huffman codes they chose aren't the best ones anymore and releases new hardware that uses different codes. Will we perhaps be getting a tinned mode too? Is your customization described in any sort of publicly available document that could hint at some way to name it properly? - Eric
