You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Distance codes with a length of 258 are usually encoded with code 285. However, it's technically possible to encode these with code 284, as a length of 227 (base length) + 31 (extra bits). This may not be legal according to the Deflate specification, and it's not considered good practice (Mark Adler has stated "In any case, a self-respecting deflate compressor should never produce [this code]."). deft4j currently misses two optimisations related to this:
Trying to replace code 285 with code 284 if it saves space (possibly not spec legal)
Trying to replace code 284 (with a length of 258) with code 285 if it saves space (spec legal)
Perhaps add the parameter switch -cautious (vs -reckless!) to cover this stricter conformance and for #2 ?
I think options like that would be a good idea. I might keep these two optimisations behind seperate switches, because issues related to #2 are from decoders which can't decode certain valid deflate streams, while issues related to this would be from creating possibly standard non-compliant streams.
Distance codes with a length of 258 are usually encoded with code 285. However, it's technically possible to encode these with code 284, as a length of 227 (base length) + 31 (extra bits). This may not be legal according to the Deflate specification, and it's not considered good practice (Mark Adler has stated "In any case, a self-respecting deflate compressor should never produce [this code]."). deft4j currently misses two optimisations related to this:
See #1 for previous discussion.
The text was updated successfully, but these errors were encountered: