EPUB passes IDPF validator, fails at IngramSpark and B&N upload

11 posts / 0 new
Last post

I'm designing an EPUB 3.0 for a client, and while the EPUB file validates onthe IDPF validator, the EPUB fails to be accepted by LightningSource's Ingram Spark and also Barnes & Noble's Nookpress?

What might be the causes for this?

It originally failed at Ingram Spark noting a font error, so I replaced the font from Myriad Pro to Arial, and still it gets rejected.

It should be noted, the client has uploaded various editions of the book before. And he claims to have changed the ISBN.

Any assistance would be helpful.


You did not mention the error message for 'still it gets rejected' - if there is no reason mentioned for the rejection, maybe you need to contact the programmer of this specific validator, that rejects without information, this is a clear indication for a problem in this validator.

About ISBN: Clearly, if a book contains an ISBN for itself, this needs to be different for each new published version of the book! If this ISBN is used as the identifier for the book in the OPF file, this needs to be changed in the NCX TOC-file as well, if the book has one (it has for EPUB 2 and can have for EPUB 3) - just as an idea, what can get wrong soon if an identifier is changed for some reason by some instance - no validation problem at least, if the ISBN is not used as the book identifier referenced in the OPF by the attribute unique-identifier of the root element.

I am having a similar challenge with IngramSpark. Having replaced the one font that could have been an offender with an Adobe native TT font, my direct to epub export from the InDesign (Creative Cloud) file continues to receive the same rejection notice (see below). Looking for anyone's advice.

Conversion Error: An error has occurred during the packaging process: E_PACK_ERROR http://localhost:8085/packaging/Package File%20already%20encrypted%20or%20unexcpected%20font%20mangling%20algorithm:%20http://www.idpf.org/2008/embedding Request XML was: <package xmlns="http://ns.adobe.com/adept"> <location>ftp://LIGHTNINGSOURCE\autoftp:s3tpwd@localhost/GBTargets/9780985849405.enc</location> <src>http://ebook.lightningsource.com/TitleDownload/LSCFD.dll?hdlr=ADEPT&

I am having the same issue/error as the above posts.
I have created my eBook file using InDesign CC and export as ePub 3.0.

I have been trying to upload ePub files for 2 weeks now. The ePub file is fine when run through the validator, but then Ingram/Spark rejects the file.
Last week when I called Ingram/Spark to talk to someone about the error, they told me it was an issue with the copyrighted fonts that I used.
So today, I changed all the fonts in my book to PUBLIC DOMAIN fonts - the file ran through validator fine, then uploaded to Ingram/Spark - REJECTED again.
I am DESPERATE for an answer to this problem . . .
Can anyone help?

Can't you create a test version without included fonts? (Using in CSS only the generic font-families?) Maybe this Ingram/Spark checker cannot identify and check the license of an included font-file?
Presumably the EPUB validator does not care about licenses, respectively leaves the responsibility for this to the publisher, but this Ingram/Spark tries to care about it.

A general approach for such bugs without a detailed error description is either to start with minimalistic files and increase complexity, until the bug/problem appears or alternatively one can start with the final, complete version and simplifies this step by step until the problem is gone - with such a method at least one can find out in detail the part of the book, the problem is related to and one reduce the error report to such an organisation to a minimalistic file, that does not contain much more than necessary to create the bug/problem.

And if something is encrypted somehow, one can have a test version without encryption to learn, whether the problem is related to encryption or not - and so on, testing
different hypotheses for the source of the problem by removing or adding questionable features.

By the way, something like 'ftp:s3tpwd@localhost' or 'ftp://LIGHTNINGSOURCE' does not
really look like a meaningful address for FTP - one has to find out, if this is really noted in for
example the OPF-file or a CSS-file. And within an EPUB book one cannot expect, that a user-agent really follows such external links, if they are really intended to be followed.
If a program only tries to embed something from these sources to create for example the EPUB book, one can at least check, that the intended content exists and is accessible for this program.

This file is not encrypted. It uses only one font family, Adobe Caslon Pro, There is no unusual formatting. IngramSpark says the error is caused by the server we are trying to upload through -- Verizon FIOS and ATT.

The whole point of this is to publish an ebook that closely resembles the print version. This was previously on the Kindle Direct platform as a MOBI Kindle edition.

I've tried this both as epub 2.0.1 and 3.0 and it makes no difference -- I am exporting the epub directly from InDesign CC.

When you say "generic font" what would you recommend? The IngramSpark system is supposed to accept any unrestricted OTF or TT font. Adobe Caslon Pro fits that description.

mhherr - if you don't insist on a specific font as an author, you can simply use the name of a
font-family in CSS like 'serif' or 'sans-serif' or 'monospace'. CSS recommends anyway to add such generic font family name as final value in the value list of the font-family property as a fallback, even if specific fonts are used. Because every user-agent is required to have a font for such a generic font family, it is always ensured, that the content/text/glyphs are displayed.
Users can chose, which font is used, therefore they get, what they like.
As author you do not have to care about licenses and font-file-formats, if this is sufficient.

If it matters and you add your own font, first one should check, that user-agents supporting the
font format really display the font and others use the generic font family specified as fallback in the CSS file. If this applies, remaining problems are probably related only to the checking program or both your program to generate the book and your user-agents displaying it can
have the same bug or gap. It is not necessarily easy to find out, what applies. One can create the books manually and understand its content completely to exclude the generating program, for example. EPUB 3 requires from a user-agent to interprete OpenType and WOFF, if a user-agent does not manage them, it has a bug or gap concerning EPUB 3, but if the font-file is corrupted, this needs to be fixed first before someone can be accused to do something wrong. Finally this means a lot of systematic research to find out, what goes wrong with the font-files, but with related test files/books one can localise the problem instead of guessing, what could be wrong.
To use only the name of an generic font family is one method to exclude all font-file-format
problems either for such a test or in general to get rid of the problem, if the font does not really matter ;o)

Another approach with the font-files - if you are sure to have the license to publish it - try to load the file manually on your computer and add it manually to your EPUB-archive to reduce the complexity on how to get this file - doing this, you should get rid of dubious FTP addresses and related issues difficult to understand what your book creating program is trying to do.

Another option - if you find a community working with the generating program, maybe they can help more efficiently - for example I only create EPUB books with a text editor or my own PHP scripts, therefore problems with programs from other vendors simply do not exist for my books
and I understand in detail, how my EPUB archive is generated and from which files and sources - therefore I would always recommend to understand the content of the archive in detail to find problems.
But if you use other programs and you have no interest in the technical details of the book, program specific error messages are better understood by the community using such programs.

Hello All,

This error is a frustrating one because it doesn't show up anywhere outside of the Ingram Content Management System. The error is cause by a file contained within the EPUB package called "encryption.xml". This error can be resolved by removing this file from the EPUB package. In order to do this, you can do the following:

1. Rename the file from Name_EPUB.epub to Name_EPUB.zip
2. Using the compression software of your choice (winrar, winzip, 7-zip, etc) unzip the file
3. Go into the file folder, then into the META-INF folder
4. Delete the encryption.xml file
5. Using your compression software, add the mimetype file to a zip archive using No Compression/0 Compression/Store or a similar option so that the file is added to the archive as-is
6. Add the META-INF and OEBPS folders to the archive. These may be compressed.
7. Change the name of the archive from name.zip to name.epub

If the above steps have been followed properly then the file should pass ICMS's validation checks just fine, barring any other preexisting issues.

In this case, you do not need to concern yourself with EULA or font permissions. ICMS will only distribute the file to retail partners, where the file will then be protected by Digital Rights Management (DRM) which will prevent purchasers of the book from accessing the fonts and stealing them.

- Ingram Content Group: Conversion Services

I had the same problems, here's what I found worked:

When exporting as EPUB from InDesign, stop at the EPUB Export Options dialogue box, click Advanced, then uncheck "Include Embeddable Fonts". So long as your fonts are standard (arial, times new roman, etc.), you should be fine.

I just tried this and Ingram accepted the file. Good luck and hopefully this works for you.

Re: Failure at EPUB uploads at Ingram. The directions given by ICG_ConversionServices are correct and fine as they go, but be aware that creating the new archive described will not solve the problem IF you use 7-Zip as your archival editor, at least its most recent version (as of 4/28/15). WinRAR DOES work, however, at least the current version of WinRAR. WinRAR is not free, but is shareware and you get 40 days use before you need to pay for it; it is easy to find on the web. I don't know if WinZip or any other tool works. I do not benefit by your purchase of WinRAR :)

Secondary menu