"files not listed in OPF" ARE listed. what do I do?

[lucita]

Hi everyone,

Just joined on the strong recommendation of another forum. I've successfully uploaded various ePubs to Apple's iBookstore, but on this latest title I'm getting a bizarre error:

"WARNING: Verse.epub: item (__MACOSX/OEBPS/images/._amazon_large_fmt.png) exists in the zip file, but is not declared in the OPF file"

The error in itself is clear enough, what's strange is that this file, and two others similarly named, ARE indeed listed in my content.OPF file, in the manifest section, as follows:


<item id="amazon_large_fmt.png" href="images/amazon_large_fmt.png" media-type="image/png"/>
<item id="amazon_large_fmt1.png" href="images/amazon_large_fmt1.png" media-type="image/png"/>
<item id="amazon_large_fmt2.png" href="images/amazon_large_fmt2.png" media-type="image/png"/>


I am at wit's end. I would understand if the files had different names, but as you can see from the error and the code, the file names are the same. (I don't quite get the "._" after the images/ reference in the error.)

One other strange thing is that my ePub Checker software does not catch any errors (I have version 1.1.1 for the Mac), but the Kobo team did get the same error using http://www.pagina-online.de/software/epub-checker/.

Many thanks again.

Birgitte
Anyone have any ideas? I would be so grateful for any insights.

[amyg]

The existence of the _MACOSX directory and the ._ files indicate to me that you are using the Mac's internal file compression utility to zip the file and then changing the name to epub. While you can do that on Windows, the Mac requires a 3rd party script to compress epubs properly. Fortunately, one of our members has created a convenient application that both zips and unzips epub files on a Mac and does so without causing any errors. Here's the link to the thread where he uploaded this application.

[dgatwood]

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:

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.

[lucita]

Hi Amy,

Actually no, we use InDesign to generate the ePub, and then open that up to make any necessary code tweaks by hand directly in the code.

[lucita]

to dgatwood... i must admit what you wrote is totally over my head but I can say that I took a different route to get to the ePub. We lay the content out in InDesign CS5.5, then export to ePub. This has worked wonderfully every time.

Then we open up the ePub using Stringy, edit whatever individual files need to be edited using TextWrangler or similar software, and save back to Stringy. We have at times needed to reconstitute the ePub instead of saving directly to Stringy, I wonder if that's the issue?

here is how we've reconstituted ePub files in the past:


open TERMINAL
1.) cd ~/desktop/"Folder Name"
2.) zip file.epub -X0D mimetype
3.) zip file.epub -X9rD OEBPS/
4.) zip file.epub -X9rD META-INF/

I'll try that and see if it works... but if you guys or anyone else has any other ideas I'd love to hear them. It sounds like the images are not the issue but the way the ePub is reading...

[amyg]

Take a look at the page I linked to. I think it will solve your problem.

[lucita]

OK, duh. I reconstituted the file according to what I just posted and it passed through Apple's system with flying ePub colors.

Sorry for the trouble and thank you!!

[Toxaris]

Instead of Stringy you might be better of to do the code changes with Sigil. It can directly open ePUB and also has a validation built in (not better per se, but different).

[AlPe]

Originally Posted by lucita

"WARNING: Verse.epub: item (__MACOSX/OEBPS/images/._amazon_large_fmt.png) exists in the zip file, but is not declared in the OPF file"

The error in itself is clear enough, what's strange is that this file, and two others similarly named, ARE indeed listed in my content.OPF file, in the manifest section, as follows:
<item id="amazon_large_fmt.png" href="images/amazon_large_fmt.png" media-type="image/png"/>

Please note that your sentence is NOT true: "._amazon_large_fmt.png" and "amazon_large_fmt.png" are NOT the same file. (Note the "._" at the beginning of the former, whose origin has been explained by dgatwood.)