Using Ant to Create Conforming EPUB3 Zip Packages

6 posts / 0 new
Last post

I have existing code that has been producing conforming EPUB2 packages (in that they passed at least epubcheck v2). It uses Ant to Zip the EPUB file. I am using Ant 1.8.4.

I am now updating that code to produce EPUB3s (this is the DITA for Publishers EPUB transformation) and the Ant target that does the zipping is producing EPUBs that fail using epubcheck V3 and V4 with the message:

The mimetype file has an extension of length 20. No filename extensions are permitted for the mimetype file.

Comparing this file with the same file saved by OxygenXML (which does not give this message), it appears that Ant is adding extended field data to the local file header--using a hex editor I can see that there are 20 null bytes following the filename data.

If I understand the message it is complaining about that extra field (the optional "Extra field" as defined in the Zip specification).

So clearly Ant's Zip action is adding this field, which I can't have.

Here is my Ant code:

<target name="zipepub">
<!-- Two steps because mimetype must go in first,
uncompressed. Looks like ant puts later zipped files in
first, so mimetype is in second zip task. -->
<zip destfile="${output.dir}${file.separator}${}.epub"
<zip destfile="${output.dir}${file.separator}${}.epub"

Reading the Ant docs other than the createunicodeextrafields, there is nothing that would control the generation of the extra fields in the local file header.

My question: does anyone know if it's possible to create a EPUB-conforming Zip file using Ant and if so, how?

Or, conversely, is epubcheck being too rigid in its checks, given that the local file header appears to conform to the Zip specification itself.

I could code the Zip processing myself or find an appropriate third-party library but I'm trying to avoid having any unnecessary dependencies.



I believe you just need to set base64Mode="never" to avoid the additional headers. A quick test using your code and the issue went away for me.


And for the record, the strictness around the zipping is expected. The packaging has ODF heritage, and by disallowing the optional field headers you can ensure the byte position of the strings 'mimetype' and 'application/epub+zip' (magic numbers), ensuring that the file format can be identified without having to use zip tools.

The media type identification and media type registration sections of the OCF spec spell out these details.

Granted, it makes the zip process a bit of a pain in the ass, but it is what it is...

I believe the attribute is zip64Mode, but in any case, I'm using Ant 1.8.5, which does not support the @zip64Mode attribute, so it looks like it's an issue with older Ant versions.



I upgraded to Ant 1.9.4 and confirmed that with @zip64Mode="never" specified that the EPUB file passes epubcheck.

Ha, yes, I had a conversation with someone else about base64 encoding some parameters before replying. I guess it spilled over in my addled brain... :)

Missed your version as I was skimming at the time, but glad you got it sorted out.

Secondary menu