Epub3 with javascript (oam) from Indesign, works on on Readium Chrome extension but not on IOS Readium app!

[OmarCur]

This issue is a question / bug report

Expected Behaviour

A epub3 with an embedded oam file (created in Adobe edge / animate), displays correctly and animates correctly on the chrome readium extension reader.

Observed behaviour

It does not show the animations (oam) files on the readium app for IOS.

Latest Indesign CC2019 to create an epub3 Latest Chrome with latest readium app installed on chrome on windows 10 Latest app from the appstore.

Thanks

[OmarCur]

it also does not work on epub3 reader from microsoft and adobe

[llemeurfr]

Can you please give precisions on which readium app for iOS you tested this? Is it the "R2 Reader" available on the appstore? Also, would you be able to share a sample?

[OmarCur]

Hi there, thanks for your reply

this is the url for the reader R2 reader, https://itunes.apple.com/us/app/r2-reader/id1363963230?mt=8

this link contains a test epub3 from adobe indesign cc2013 and an oam from adobe edge cc2015, adobe animatie cc2019 can also generate and oam file but gives the same result as Edge

https://www.dropbox.com/s/fr3qwqeal4bcozo/test.epub?dl=0

Thanks again

[danielweck]

Thank you for providing a test EPUB.

First of all, the publication contains a number of application/html documents, instead of application/xhtml+xml. Is that valid EPUB3?

The Readium2 test app for desktop platforms fails to load the iframe because of non-XML HTML (see latest builds for Linux, Windows, and Mac at r2-testapp-js https://github.com/readium/r2-testapp-js/releases ). I will file an issue for this, as I don't think it should happen.

So, I changed the HTML documents to XHTML, and I am now seeing this error from Adobe's edge.6.0.0.min.js runtime: "Uncaught DOMException: Failed to set the 'innerHTML' property on 'Element': The provided markup is invalid XML, and therefore cannot be inserted into an XML document."

I now understand why HTML was chosen instead of XHTML :) Do you have any valid EPUB3 document that works in other reading systems (e.g. iBooks) but doesn't in Readium apps?

Thanks!

[JayPanoz]

Is that valid EPUB3

Last time I checked – that was like 2 years ago, when designing an Ulysses.app theme –, epubcheck threw errors about that.

Looks like epubcheck is also checking what the extension is, cf. https://twitter.com/rcgordon/status/1080984878986842113

I don’t know what the assumption is, mind you, but can remember weird things happening if the extension is .html and not .xhtml, and files are served “statically” – file:// non-network scheme.

Uncaught DOMException

Yeah I mean, you’ll encounter a lot of those when scripts/libs are designed for HTML – brings back memory of the EDRLab x OECD prototype.

However, I would expect HTML to be OK when loaded into an iframe. Can confirm it is in at least some apps.

[edit] Actually, iframe + .html has even been discussed during an eprdctn hour 4 years ago. There’s this tweet by Ken Jones for instance, but I can remember him providing examples, etc. https://twitter.com/CircularKen/status/659387781714694144

[OmarCur]

Hi all,

Thanks for your quick responses, this files comes directly from indesign cc2019, with a Adobe Edge OAM file embedded. We can replace the Adobe Edge with Adobe Animate but it gives the same outcome.

This document works in the Chrome Readium extension and it worked in our own app based on the Readium sourcecode.

I was hoping that the R2 readium ios app would behave the same.

These files do not work on other epub readers, i havent tested it yet on ibooks.

Although Adobe creates these epub3, their own reader does not displays it correctly.

Any help is appreciated

[OmarCur]

Hi there,

to be a bit more up-to-date i have created a epub3 file from Indesign cc2019 and in the indesign document is a oam file loaded from animate cc 2019.

https://www.dropbox.com/s/9nqglxhfamf3zu6/test2.epub?dl=0

thanks

[llemeurfr]

The main issue is that is the document does not pas EPUBCheck, Adobe should correct its export first (however, I'm not sure they will be as responsive as we are).

The fact that it worked by chance on one variant of the Readium kit / test app doesn't mean it must work on every variant. Nevertheless, having Readium work correctly with html files is a step toward Web publication support, therefore this is an interesting exercise IMO.

[OmarCur]

Thank you again,

Did you look at both epub3 documents on the the Chrome readium extension, to see how it should look and work and how it looks in Indesign?

https://chrome.google.com/webstore/detail/readium/fepbnnnkkadjhjahcafoaglimekefifl

[JayPanoz]

Took a very quick look, and it’s true that it doesn’t pass epubcheck.

Corrected the navdoc, but then it says Thumbs.db can’t be found, except it’s definitely here and I’m wondering whether that couldn’t be a MacOS-specific bug? – couldn’t test on Windows yet.

However, the less obvious issue is that the HTML document is not a spine item, it’s loaded into an iframe, so you’ve got something like this:

• placeholder-file.xhtml
  • iframe src="animation.html"

And this (iframe loading html doc), to my knowledge, has never been reported as a warning/error by epubcheck because it’s valid.

Actually, it’s even a popular way to use the HTML exports from animation/interactive authoring tools (animate CC, Hype, etc.) in EPUB3, in order to get around the “spine items must be XHTML” rule.

So I definitely agree it would help to have samples passing epubcheck to reduce the issue to “html doc in iframe”, because it could be another error – cf. thumbs.db.

[JayPanoz]

Corrected the first test file and it’s now valid.

Just checked to make sure there’s no other issue and it works in ADE 4.5 and iBooks on MacOS.

Corrected file can be downloaded here: https://www.dropbox.com/s/ssuwv96sohco1sr/test__created-with-epubcheck.epub?dl=0 (@OmarCur hope you don’t mind me sharing the corrected file.)

[OmarCur]

Even the simplest Indesign epub3 document, with one image and some text does not pass the epubcheck

https://www.dropbox.com/s/pd8p02uku7v7gjw/test3.epub?dl=0

[JayPanoz]

Yeah that’s because your table of contents is empty. If you add an item to it, it will pass epubcheck though.

@llemeurfr to “clarify” the overarching (technical) issue, and I’ll let @danielweck correct me if I’m wrong: it’s about deciding whether all apps must render HTML documents in an iframe, given it’s already used by authoring software/authors as a way to get around XHTML spine items for their interactive widgets.

[JayPanoz]

Further notes if that can help…

Turns out this case isn’t handled the same depending on platform/Reading App, even when they are using the Readium SDK.

iBooks iOS → blank iframe

Readium SDK on iOS is somewhat consistent and most apps using it will render the HTML in the iframe as expected (e.g. Cloudshelf, Bookari, Lisa…)

Readium SDK on Android is somewhat consistent too and most apps using it will try to render the HTML as XHTML so you get an XML error.

That should help with “deciding whether all apps must render HTML documents in an iframe” since there’s no consistency irl.

[OmarCur]

Can someone explain why the epub3 with oam file works correctly on the chrome readium and on our own build app (based on the readium sdk) and not on the R2 IOS app or any other Readium reader.

Is it a security thing on IOS and on other readers?

[JayPanoz]

@OmarCur

To put it simplistically…

OAM file is a package that can be used in InDesign. It contains a webpage + assets (images) and scripts. So what you have in the EPUB is basically a folder with an HTML file + images + scripts.

The issue is EPUB content documents must conform to the following properties: https://w3c.github.io/publ-epub-revision/epub32/spec/epub-contentdocs.html#sec-xhtml-conf-content

So what InDesign is doing is using an XHTML “wrapper” with an iframe pointing to your HTML document. The sole purpose of this is to get around this “Content Conformance” list in the spec.

So basically, you can expect inconsistencies in the sense it’s some sort of hack on part of InDesign. Some developers won’t expect HTML documents but only XHTML, then you have technical issues on top of it. So it’s really “working more by chance” than by design (© Laurent).

I’ve opened an issue in the epub revision repository in an effort to “standardise” that use case.

Note that some Tumult Hype users have been transforming their InDesign export to meet the XHTML requirement – albeit indirectly, by making it work in iBooks on iOS.

[OmarCur]

Our plan is to create our "own" reader, which we partly have but since the project has been on hold for a "while" aka a couple of years. We are now just "updating" our knowledge. It is, of course, excellent security creating epub documents only you can read :) but we were hoping for a "leap" in content creation. To find out that the last 3 or 4 years the amount of progress is minimal and we are facing the same issues is a bit of a disappointment.

One more question, is there a way to manually change the contents of the epub document (i know it is just a zip file) , so that it becomes more compatible?

if we can create all the documents and create a parser that changes a couple of things in the epub to be more compatible it would save the day?

Thanks

[JayPanoz]

Is there a way to manually change the contents of the epub document

You could change the HTML file to XHTML but it’s likely you’d get errors for almost every single one of them.

It is my understanding scripts are created with HTML in mind, so you’d have to change those as well (must close HTML elements, attributes must have a value, etc.) though, which is the trickiest part.

I’ve adapted a JS library for XHTML a few years ago, and it’s certainly not trivial – the road is paved with obscure DOM Exceptions.

However, you would probably be able to catch most of those exceptions by targeting the innerHTML property, it’s just that parsing JS to automate changes is kinda uncommon – although, unsurprisingly, you can do it in JS itself (and interestingly, they provide docs in EPUB)

[OmarCur]

Thanks Jay, we are more content creators then we are developers and this is a bit out of our comfort zone. If we have to create 1000's of small interactive animations, it is going to be a challenge to make them compatible :(

[JayPanoz]

Yeah I can understand that.

I mean, it would be appreciated and possibly useful if you could quickly summarise your context/workflow in the issue I opened in epub-revision.

With design tools, JavaScript libraries, etc. using HTML, this is the underlying issue for graphic designers and content creators – and one big reason why some decided to use apps instead. They can’t use the tools they’re already using, other export formats work a lot better out of the box, etc.

Mind you, HTML vs XHTML is kinda of a heated debate but it would be nice to have more direct than technical inputs.

As the saying goes in the group, “interactive content is very expensive to create.” But it’s kind of a chicken and egg problem, as it’s in part expensive to create because you can’t re-use a significant part of the ressources already available without adapting it first – which is, as you said, out of the comfort zone of a lot of people.

[JayPanoz]

Just to document this, so that this issue be closed.

First of all, the publication contains a number of application/html documents, instead of application/xhtml+xml. Is that valid EPUB3?

So no, apparently not. The application/html document should have a fallback.

Reported the issue in epubcheck (cf. reference above).

[OmarCur]

Hi,

we have made a quick test with Hype and Indesign, hoping for a different result in comparison to Animate and Indesign. Unfortunately not:

If you are interested, this is the file

https://www.dropbox.com/s/e7tkp94ov8ue0r5/test4-hype.epub?dl=0

[JayPanoz]

@OmarCur As a quick follow-up, it looks like epubcheck – used by resellers, etc. – won’t report that as an error, cf. https://github.com/w3c/epubcheck/issues/985#issuecomment-470646554, since it’s been taken advantage of in the real world and that would invalidate those working files.

Bear in mind that doesn’t necessarily mean all Reading Systems/Apps will support it though – XML versus HTML.

And obviously, thanks for all the samples. This is greatly appreciated, especially as people often don’t provide those for debugging. 👍