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
The current output format is fixed to the six-bit code, which is optimized for js13kGames submissions. There are numerous other possibilities though and I'd like to reserve the -F|--output-format option in the CLI for this purpose. For the API it would be probably new method to be used instead of the current Packer.makeDecoder.
The default would remain as the six-bit coding, an explicit option being -F6. The first digit denotes outBits which is the number of bits per each coded unit. There may be following characters if there are multiple output formats with the same outBits or it requires a manual intervention (therefore we would probably never have -F8).
Each possible future format would go into there own issues. In this issue I'd document the current six-bit coding.
-F6: Six-bit coding
This is the default and only possibility as of 2.1.0. The compressed data is encoded into a template literal, where a code unit k is encoded as a code point k or k + 0x40 so that the escape sequence is not required. The latter is preferred since they coincide with alphabets, but the former is desirable or even required when k is one of the following:
0x1c (because 0x5c is \)
0x28 (which is (, the first line has to include this character when -D is not in use)
0x3d (which is =, the first line has to include this character when -D is in use)
0x3f (because 0x7f is not printable)
This format is designed to be "compressed" again with the Huffman tree. This is ensured by making every code unit corresponds to a (mostly consecutive) set of 64 characters and minimize the number of characters not in the set (we can't completely get rid of them because ` has to be somewhere in that line). The Huffman tree needs to encode characters not in the set so the actual coding rate is slightly below 8 bit/char even after DEFLATE, but the optimal tree should result in at least 7 * (384/385) = 7.979 bit/char.
The text was updated successfully, but these errors were encountered:
The current output format is fixed to the six-bit code, which is optimized for js13kGames submissions. There are numerous other possibilities though and I'd like to reserve the
-F|--output-format
option in the CLI for this purpose. For the API it would be probably new method to be used instead of the currentPacker.makeDecoder
.The default would remain as the six-bit coding, an explicit option being
-F6
. The first digit denotesoutBits
which is the number of bits per each coded unit. There may be following characters if there are multiple output formats with the sameoutBits
or it requires a manual intervention (therefore we would probably never have-F8
).Each possible future format would go into there own issues. In this issue I'd document the current six-bit coding.
-F6
: Six-bit codingThis is the default and only possibility as of 2.1.0. The compressed data is encoded into a template literal, where a code unit k is encoded as a code point k or k + 0x40 so that the escape sequence is not required. The latter is preferred since they coincide with alphabets, but the former is desirable or even required when k is one of the following:
\
)(
, the first line has to include this character when-D
is not in use)=
, the first line has to include this character when-D
is in use)This format is designed to be "compressed" again with the Huffman tree. This is ensured by making every code unit corresponds to a (mostly consecutive) set of 64 characters and minimize the number of characters not in the set (we can't completely get rid of them because
`
has to be somewhere in that line). The Huffman tree needs to encode characters not in the set so the actual coding rate is slightly below 8 bit/char even after DEFLATE, but the optimal tree should result in at least 7 * (384/385) = 7.979 bit/char.The text was updated successfully, but these errors were encountered: