View Full Version : File rejected by Apple


awp
07-31-2010, 07:12 PM
One of our users submitted an EPUB book for inclusion into the iBookstore. The file passed the epubcheck validation test. But this file was rejected by Apple with the following error message:

Apple ERROR ITMS-4000: Line 89 column 63: bad character content for element at XPath/package/book/assets/asset[2]/data_file/file_name.

I googled for this error. The only site page where it is mentioned is a bug report page of Calibre:
http://bugs.calibre-ebook.com/ticket/5773

I do not have the "guilty" EPUB file (there are privacy concerns I guess).

Can anyone say what this error could mean?

Thanks.

Jellby
08-01-2010, 05:33 AM
Could some file(s) inside the ePUB have a name with non-ascii characters?

charleski
08-01-2010, 08:58 AM
It's very difficult to say without seeing the actual epub. Since it's coming from a Word file there shouldn't be any encoding issues in the file names, since they're all generated by AWP. Maybe ask if they can extract just the .opf file and send it to you.

GeoffC
08-01-2010, 09:40 AM
From experience passing epubcheck is no guarantee of anything .... Pity the error message was not more expressive .... !

awp
08-01-2010, 07:14 PM
Since it's coming from a Word file there shouldn't be any encoding issues in the file names, since they're all generated by AWP.

Exactly. The EPUB file contains multiple HTML files. Their names are 1.html, 2.html, and so on.

It's very difficult to say without seeing the actual epub. Since it's coming from a Word file there shouldn't be any encoding issues in the file names, since they're all generated by AWP.

The user agreed to send me the EPUB file. It is copyrighted. I will have to remove it from my computer after examining it. So regrettably I cannot post it to the forum.

It contains 31 HTMLs (chapters). All use a very basic formatting. I have checked all the files from the EPUB package. There is nothing suspicious in any of them at "line 89 column 63". Only plain English text.

Maybe ask if they can extract just the .opf file and send it to you.

I suppose that posting the .opf file is not a problem since it is rather a "technical file" (please see attachment). But it is unlikely that the .opf file could be the problem.

charleski
08-01-2010, 08:51 PM
It looks perfectly fine, they haven't added anything else to the package after it was generated, which is why I suggested looking at the opf.

Right now I think the primary suspicion must be some bug in Apple's system.

GeoffC
08-02-2010, 12:40 PM
and there is no line "89" in the .opf

kovidgoyal
08-02-2010, 12:42 PM
Your problem is that the NCX specification does not allow filenames to start with numbers. Valid identifiers have to start with a letter and use only letters, numbers and underscores.

As far as I know Apple is the only organization simple minded enough to impose this restriction.

charleski
08-02-2010, 02:40 PM
Your problem is that the NCX specification does not allow filenames to start with numbers.
Are you sure about that? Section 3.3.1 (http://www.niso.org/workrooms/daisy/Z39-86-2005.html#Allowed-Char) doesn't mention anything special about the first character of a filename. You might be thinking of ids.

kovidgoyal
08-02-2010, 04:06 PM
I've had people open tickets about it and changing the filename got the epub accepted by Apple. You're probably right in that the spec doesn't specify that convention for the filename, but I'm fairly certain Apple does.

Of course, as with any closed system, no way to be sure, so I could be wrong, but given that the original error message points to a file_name...

awp
08-02-2010, 05:35 PM
I have just sent a test version of Atlantis Word Processor to that user. It generates HTML filenames starting with a letter. I will let you know if it worked.

Thanks.

st_albert
08-02-2010, 08:03 PM
I have just sent a test version of Atlantis Word Processor to that user. It generates HTML filenames starting with a letter. I will let you know if it worked.

Thanks.

Hmm, I am looking forward to the answer to this. We have submitted several epubs to Apple that were initially created from .rtf via Atlantis, and -- I just checked -- they have filenames starting with numbers (1.html, etc.). So far they have been accepted by Apple, and AFIK are offered for sale on iBooks.

eping
08-02-2010, 11:59 PM
As far as I know Apple is the only organization simple minded enough to impose this restriction.
I agree. I found Apple is also silly enough to report error if there's additional characters after </html>

awp
08-03-2010, 07:21 PM
I have a reply from the user (she is a production manager at a publishing company). Filenames starting with numbers are not a problem, even to Apple (to iPad and iTunes Producer). She said that they have 102 titles currently active at Apple and 136 that have been submitted and are awaiting acceptance, and all were created with Atlantis Word Processor. They always submit Atlantis EPUBs "as is", without "tweaking" them. That "faulty" eBook is the only file that keeps rejecting. By the way, that eBook contains adult material. Maybe this is why iTunes Producer does not want it to get through. :rolleyes:

She also said that she will start the file over from scratch and rebuild it to see if that will fix it.

JSWolf
08-07-2010, 03:32 AM
Given that it's Apple, chances are the book is fine and that it's the content that gets it rejected.

MyQuestBe
08-09-2010, 06:59 PM
I got this same error message and tried a variety of solutions, (Opening the metadata and analyzing it, changing chapter names in my ePub file (They started with a number) removed spaces and hyphens from file names, resaved files from scratch, etc.) none of which worked. Given the error message references "assets/asset[2]/data_file/file_name", I figured it must have something to do with the second asset in the asset screen of iTunes Producer, which is the art for the ibook cover. I opened my cover art file and found its size was 420 x 599, when it should've been 400 x 600. I resized it, made sure it was saved as a .jpg, resubmitted it and...problem solved.

It was like I knew what I was doing.

charleski
08-09-2010, 10:46 PM
I'm glad to see that Apple isn't letting their reputation for ease-of-use interfere with the sacred tradition of meaningless error messages. It's amazing how many computer problems end up being solved by just fiddling with it till it works.
:goodjob:

kovidgoyal
08-10-2010, 11:27 AM
Wow that is weird!

awp
08-10-2010, 01:59 PM
I got this same error message and tried a variety of solutions, (Opening the metadata and analyzing it, changing chapter names in my ePub file (They started with a number) removed spaces and hyphens from file names, resaved files from scratch, etc.) none of which worked. Given the error message references "assets/asset[2]/data_file/file_name", I figured it must have something to do with the second asset in the asset screen of iTunes Producer, which is the art for the ibook cover. I opened my cover art file and found its size was 420 x 599, when it should've been 400 x 600. I resized it, made sure it was saved as a .jpg, resubmitted it and...problem solved.

It was like I knew what I was doing.

The "faulty" EPUB file of our user contains a 500 x 750 cover image. It can be easily sampled down to 400 x 600. I have forwarded this tip to her.

Thank you, MyQuestBe.

st_albert
08-10-2010, 07:29 PM
We usually scale ours to around 800x1200px and in png format. No rejections by Apple so far for that reason.

So yes, it is really weird.

The iTunesConnect PublisherUserGuide (see post #1 in the following thread:

http://www.mobileread.com/forums/showthread.php?t=90011&highlight=iTunesConnect )

only says this about images:

Images
* Images that have any unused or transparent areas should be PNG format with transparency.
* Because there is limited screen real estate, book images are automatically scaled. For this to correctly work, images should be at the correct intrinsic dimensions when created instead of hard coding dimensions in the image tag itself.
* To ensure proper viewing of images in content, use the HTML img tag instead of wrapping images in svg:img.
* The maximum recommended size is about 11 MB of un-encoded image data per chapter.

(edited to add link to Apple documentation)

awp
08-11-2010, 09:28 AM
You are right. The image size is also not a problem. I have a reply from the user:

Actually, I haven't had any problems with the other titles that have successfully been absorbed into the iBookstore with regard to graphic size. The only place they seem to be itchy when it comes to graphic size is the artwork you upload for the product page, which must be 453 x 680. A 500 x 750 jpg is standard in all of our books, and nobody's hacked up hairballs over it.