Errors while validating EPUB

[dgatwood]

IIRC, the folder name should also not be there. On OS X, I just do:

cd extracted_book_directory
zip -Xr9D ../filename.epub mimetype * -x .DS_Store

Because the mimetype file is so small (in length), it is always more efficient to store it uncompressed, so in practice, no zip utility should ever compress it. You don't even need to worry about that; just make sure that it is the first file you pass to the zip utility.

BTW, if you want to squeeze an extra few percent from your delivery costs, I highly recommend installing advzip and doing:

advzip --recompress filename.epub

[pdurrant]

Originally Posted by dgatwood

IIRC, the folder name should also not be there. On OS X, I just do:

If you're referring to the commands I posted, the folder name was not in the commands.

If you're on OSX, I'm astonished that you're using the command line instead of the easy drag&drop applescript mentioned earlier.

[crankypants]

Shortly after I posted my last post in this thread, my programs stopped running from the flash drive I develop on. The flash drive is only a year old. I tried installing Strawberry Perl and my other tools on 2 more flash drives with the same error: the program just locks up if run from the flash drive.

I'm currently installing all my tools to my c: drive, which seems to work, and leaving my project files on the flash drive.

[eschwartz]

Originally Posted by dgatwood

IIRC, the folder name should also not be there. On OS X, I just do:

cd extracted_book_directory
zip -Xr9D ../filename.epub mimetype * -x .DS_Store

Well, I assume that is why pdurrant's post explicitly referenced a mimetype file in currentdir.

Because the mimetype file is so small (in length), it is always more efficient to store it uncompressed, so in practice, no zip utility should ever compress it. You don't even need to worry about that; just make sure that it is the first file you pass to the zip utility.

Is it worth the risk?

In order to get away with using one command, instead of two, in a shell script, I don't see why you should be making that assumption.

[dgatwood]

Originally Posted by pdurrant

If you're referring to the commands I posted, the folder name was not in the commands.

No, I was just speaking generally.

[dgatwood]

Originally Posted by eschwartz

Is it worth the risk?

It is pretty much guaranteed. The string "application/epub+zip" is only 20 bytes long. Using the DEFLATE algorithm more than doubles its length to 42 bytes. No zip tool worth its weight in manure is going to choose to use the DEFLATE output if doing so would more than double the length of the file.

[eschwartz]

Originally Posted by dgatwood

It is pretty much guaranteed. The string "application/epub+zip" is only 20 bytes long. Using the DEFLATE algorithm more than doubles its length to 42 bytes. No zip tool worth its weight in manure is going to choose to use the DEFLATE output if doing so would more than double the length of the file.

Understood...
But even a zip tool that isn't worth its weight in manure but is technically creating a perfectly valid ZIP, might exist.

Since I would anyway suggest scripting the EPUB zipping (much less typing of exclusions plus various magical incantations, and you can pass a directory + auto-name the EPUB), there is no loss in adding an extra line, and it doesn't really take longer to zip... so why rely on "should"s? It is just generally a bad idea to rely on undocumented assumed (rightly so) behavior, but especially when there is literally no downside to being extra careful!