Files in OS X's native volume format, HFS+, can have a lot more information than just the raw data of the file itself. They can have resource forks, extended attributes, and probably a few other things I'm forgetting at the moment. These things cannot be reliably stored on volumes in many other disk formats. So OS X instead stores that information in a separate file, named the same as the original file, but prefixed with "._". These are called AppleDouble files.
OS X uses this same structure when writing zip files and tar archives, but in the case of ZIP files, throws them in their own directory (__MACOS).
Because of this, although you can certainly use the zip tool to construct EPUB files, you have to specify various flags to get the right behavior.
cd book_folder
zip -Xr9D /path/to/output.epub mimetype * -x .DS_Store
should generally work.
The -X folder disables extended attributes (which are stored as a fork in the ._ AppleDouble files when represented in a ZIP archive). It also disables various additional fields in the zip file's TOC that violate the EPUB spec.
The -r flag tells it to include directories recursively.
The -9 flag tells it to spend extra time to achieve maximum compression.
The -D flag tells it to omit entries for the directories. This isn't strictly necessary, but it should save a tiny bit of space.
Pedantically, the FreeBSD folks suggest doing this:
Code:
zip -X0 /path/to/output.epub mimetype
zip -Xur9D /path/to/output.epub *
to make absolutely sure that the manifest file never gets compressed. However, in practice, as far as I can tell, the OS X zip utility never attempts to compress the manifest file anyway, so this is probably unnecessary.
If that doesn't work, adding
--datafork should fix the only other cause of ._ files appearing. Unless, of course, there are actual ._ files in your source folder, in which case... well, nuke them.
