EPUB (fixed layout) animation error

[Tibor36059292rjtr]

Hello,

I have created an EPUB (fixed layout) file with animations in Indesign, which works without problems on a Thorium reader on PC. When I checked the file on the EPUB checker, it reports errors with the animations, and it reports similar or the same error everywhere with all the animations:

»data-idGenAnimationEndState« is not valid custom attribute (it must have at least one character after the hyphen, be XML-compatible, and not contain ASCII uppercase letters).

For example, if I try to change the uppercase letters, it no longer reports an error, but the animations don't work anymore. Does anyone have any ideas or advice on how to solve this problem?

[James Gifford—NitroPress]

which works without problems on a Thorium reader on PC.

Then you're done.

While most EPUB validators are a waste of time, EPUBchecker is as much the gold standard as is Thorium Reader. If your EPUB works on Thorium, any further checking, testing or attempt at optimization is... probably wasted. Clearly, this XML flaw doesn't keep the document from working on the most highly standardized reader you can get. You can spend a lifetime on this kind of all but phantom flaw and gain nothing.

That said, animations in EPUB are out on the flapping ragged edge, and I'd be surprised if any amount of code and doc editing could correct the error and preserve animation functionality.

[Tibor36059292rjtr]

Thanks for feedback. Actually, the animations work on all the readers I've tried now, but what I'm worried about is the distribution across online platforms, namely that these errors, which don't affect the performance of the EPUB file at all, would result in the file being rejected.

[BobLevine]

If you insist on using fixed layout epub you are likely to be in for a bit of pain. At this point, I wouldn't touch a job with it unless it was for a limited internal distribution that could be tested on specific devices with specific reader applications.

[Tibor36059292rjtr]

I am aware of the disadvantages of EPUB fixed layout, but the e-book is a children's cookery picture book for which a fixwd layout is probably more appropriate than a reflowable layout. So the problem is not the format, because the book and the animations that were made with Indesign otherwise work fine on all the readers it was tested on, the only problem is the code that Indesign generates that does not follow the xml standard. This problem is only detected by the EPUB checker, and does not affect the performance of the file. I have also prepared a file without animations, and it is error-free, but I would like to publish an e-book with animations, so I would like to fix this problem.

[BobLevine]

What you would like to do borders on impossible. I'm sorry, but that's simply the way it is.

[James Gifford—NitroPress]

I think Bob's being a little absolute, but not wrong. EPUB is... a highly imperfect platform. It works within certain guidelines, for certain users and in certain ways, but you can't necessarily do everything at once. We've become used to endless interactivity and animation and 'perfect' presentation of things digital, but the truth is that only a few narrow technologies do that, primarily this one — web-based HTML/CSS with both browser and server support of things like animation. Nearly everything else is still at the "works on the inventor's system" level, and EPUB is working from a 13-year-old standard and an ecosystem of readers and tools that are almost all amateur fan productions.

Like the old print shop poster ("You want it good, fast and cheap? Pick two and call me back!") I think you're going to have to reduce the feature set for this project if you want success.

That it works on all the readers you've tried it on should be enough for distribution, but many of the vendors do demand strict validation compliance.... which is often meaningless, but they're as tired of the fallout from broken books as everyone else.

[Tibor36059292rjtr]

Thank you both for clarifications. I was also counting on the fact that the full range of functionality will probably not be able to meet the requirements of all web platforms, so we have the possibility to avoid this problem by simply uploading the EPUB file without animations, which will solve the issue, at least as regards the animations.

[James Gifford—NitroPress]

I'd just drop the animations from the project unless you want to package two editions, one with and one without, for end-user compatibility. Not easy to do through resellers/vendors.

Not quite sure what your web comment means... after the chaos of the HTML4/XHTML/browser war era, in which no two browsers showed the same rendering of simple pages without scads of conditional code, the web has become almost astonishingly pan-compatible. It's only in a few minor areas that some browsers don't have full/matching support. An HTML5/CSS3 web page is as close to a universal document/display page as the world has, I think. You have to get pretty convoluted or tricky for the standard range of browsers not to show the page identically.

ETA: Might have misread you  — I now assume by 'web platform' you mean the various web resellers of EPUB. Sometimes you just have to pick and choose your reseller rather than struggle to get and keep a book listed with all. (In my experience, 90% of sales are through Kindle, and the EPUB distributors have 10% of that level, at most, and even collectively only have about 20%. It's not a great place for promotional selling; at most, they are convenient outlets to which your own marketing efforts can drive buyers. I'd just pick one that works well for you and not bother with the rest. The chance/pickup sales won't be worth the hassle.)

[rayek.elfin]

The solution is simple. Crack open the epub, find and replace all »data-idGenAnimationEndState« in ALL files, replace with a label that doesn't throw the epub checker's error.

Zip it up again (making sure the mimetype file is not packed and remains uncompressed as a file in the epub).

Rename to .epub extension if needed. Test again.

Done.

PS you can do the search and replace step easily in Visual Studio Code. Open the folder with the unzipped files in VS Code, then search and replace in files. (Edit menu).

[James Gifford—NitroPress]

Well... leaving out the idea that EPUB surgery is obsolete, are you sure there are no external calls to that function? Maybe not in this case, but it doesn't help to rename something internally if an external library, server or database (for example) uses it.

Also that — like all surgery — it has to be repeated, without error, every time the book is re-exported for any reason.

[rayek.elfin]

I've run into this issue myself before. It works. Those function names are repeated across several files, with up to 9 or so instances or more (depending on the number of pages with animations, of course).

But yes, I agree: it's awkward, and this step shouldn't be required. It is kinda embarrasing that the developer(s) behind the epub export didn't check their own epub output with EPUB checker.

That said, the entire FLX epub format is an immeasurably bigger embarrassment...

 

[James Gifford—NitroPress]

Some problems may not be worth solving. I'm not at all sure why this one is occurring, especially given that there is no problem with the file in pretty-much-the-standard reader.

The insistence of some resellers on validation perfection, is, perhaps, a problem in itself. (Although, peeking in horror as I do at some of the amateur publishing forums etc., maybe it's just necessary self-defense. 🙂 )