Editing Compress (software) (section)

== Special output format ==
The output binary consists of bit groups. Each bit group consists of codes with fixed amount of bits (9&ndash;16). Each group, except the last group, is aligned to the number of bits per code multiplied by 8 and right padded with zeroes. The last group is aligned to 8 bit octets and padded with zeroes. More information can be found at an issue on the ''ncompress'' GitHub repository.<ref>{{Cite web |title=compression with 9 bits don't work · Issue #5 · vapier/ncompress |url=https://github.com/vapier/ncompress/issues/5 |access-date=2024-09-17 |website=GitHub |language=en}}</ref>

Example:
: Suppose the output has ten 9-bit codes, five 10-bit codes, and thirteen 11-bit codes. There are three groups to output containing 90 bits, 50 bits, and 143 bits of data.
:* First group will be 90 bits of data + 54 zero bits of padding in order to be aligned to 72 bits (9 bits × 8).
:* Second group will be 50 bits of data + 30 zero bits of padding in order to be aligned to 80 bits (10 bits × 8).
:* Third group will be 143 bits of data + 1 zero bit of padding in order to be aligned to 8 bits (since this is the last group in the output).

It{{What|date=September 2024}} is actually a bug. LZW does not require any alignment. This bug existed for more than 35 years and was in the original UNIX ''compress'', ''ncompress'', ''gzip'' and the Windows port. All ''application/x-compress'' files were created using this bug.<!--What is "specification" here?: So we have to include it in output specification.-->

Some compress implementations write random bits from uninitialized buffer in paddings. There is no guarantee that the paddings will be zeroes. The decompressor must ignore the values in the paddings for compatibility.