JJR22 wrote:
Ok, thanks!
A more important question, though, is why is Apple putting ebook authors through this torment in order to publish books?
Because various tools that generate EPUB documents can be buggy, because verifying EPUB files using reader apps is tedious and with incomplete coverage at best, and the easiest way to reduce the numbers of issues arising from those buggy tools and to reduce the support costs of purchasers encountering errors in an EPUB reader is to validate the EPUB files.
File format validation is longstanding practice in publishing (and programming, for that matter) with validation / lint / preflight tools widely used for various formats including PDF and EPUB files, as well as for source code files (compilers), and with many other sorts of data and metadata files.
It’s also a way to be able to point st a specific reader being buggy, too.
If validation isn’t available or doesn’t happen, we get messes. Like, for instance, the compatibility issues that arise with the differing interpretations of FAT, as found across the many different FAT storage implementations.
TL;DR: Apple doesn’t want to get overrun with support reports and refund requests for whatever (possibly-buggy) EPUB tool some author used.
Why this case? Presumably, this EPUB is big, or comparatively complex, or both. Or maybe Java or the EPUBcheck tool itself got bigger..
