Quote:
Originally Posted by Ankh
The question is, should the epubcheck and flightcrew be updated, or should we petition the IDPF to accept the experiences of the actual implementation relaxing the requirement in the process? |
What a mess... I decided to follow through on contacting IDPF. So before doing that, I went on to verify that command line zip parameter is really matching the value in local header, mentioned in the spec. It is
not. The compression method field in the header, in the current zip source, can have values:
0-Store
8-Deflate
12-bzip2
So, the standard is prohibiting using bzip2 compression, or any new compression that might be added to the Zip utility at the later date. Which is sensible, as it enforces the known baseline that can be met today and in the future.
The numbered parameters in zip command line utility provide a trade-off between compression speed and compression efficacy. -0 will force "store" method, anything else will use "deflate". So, even if you use value "9", the local header (one for each compressed file) field, mentioned in the spec, will be assigned a value of 8, satisfying spec requirement. What will create a non-standard file and break this requirement is using parameter "-Z bzip2", which is not suggested by any internet epub creation guide.
I do apologize for the mess that I created. My original message will be modified to remove FUD that I created.