My problem: the document created with Adobe InDesign 17.4 and exported as epub 3.0 (fixed layout) works fine on Apple Iphone. However, Android, the text is garbled and rendered with jumble text, missing tabs, and missing spaces. The adobe digital edition app was as the epub reader for android.
How can I fix the problem and with which epub readers can the epub created with indesign be displayed and read correctly on Android? See attached files.
Thank you for your support
Has nothing to do with InDesign. I wrote a blog post about this awhile back and sadly, not a whole lot has changed. The Fixed Layout EPUB Missing Piece: Reliable Readers for Windows and Android • BobLevine.us
Concurring with @BobLevine here — EPUB readers vary enormously not only between platforms, but across each platform as well. There are a variety of reasons but much of it traces to developers for each platform making choices that (they think) suit their users (or follow OS developer guidelines). That's before the layer of development where someone simply has a better/simpler/tangent idea about how to do something.
EPUB is an incompletely defined standard much like HTML used to be, so every app maker fills in the gaps in their own way. It means that compatibility is limited to a base set of "compliant" readers and ones that add on but don't change basic features.
Apple's reader is solid within the platform (and the Apple Bookstore products) but varies considerably from the standard. It's not the one to develop for unless you are going to limit distribution and sales to the Apple platform. Far better to develop to one of the standardized readers, such as Thorium or (with some limits) Calibre, and then tweak as needed to keep that compatibility while still making iBooks and other readers happy.
Redevelop your document to display properly in Thorium and you will find it is compatible with most — but not all — other readers.
Not much to be added after Bob's and James' answers, except that FXL ePub is far too fragile as a format to depend on for multi-platform publication and that it is a much better idea to publish to the web or a web/app.
Unfortunately this means either depending on a third-party commercial plugin (In5) or the old free html export plugin (which can be downloaded here: https://www.gilbertconsulting.com/scripts ) but still requires manual CSS code to make it adjust responsively to any screen format.
ID exports directly to HTML without a plug-in, with many of the same export controls as EPUB (since, of course, they are very similar formats).
On the whole, ID's export to HTML is nothing I'd consider a finished-doc output, but with CSS adjustments at the export stage and some touch up in Dreamweaver (or just at the code level), it's acceptable.
But my rule is that if you want fixed pages, use PDF. FXL EPUB is a weak, fragile substitute at best. If you must use EPUB or want a more generic e-book, use reflowable EPUB.
The web export in InDesign (Export-->html) produces a mess of separated layout elements, and the layout is ruined. At least, unless I am missing a setting or a different way to export?
It would be helpful if InDesign could export each page to a SVG file. But as far as I am aware it cannot. It is not even possible to select SVG in the Object Export Options. (yes, there are workarounds with exporting to pdf and converting to SVG in other design software, but it seems like low-hanging fruit to me.)
I agree, the HTML export is... basic. But as with reflowable EPUB and most other final formats, it's a matter of optimizing the document for that final form. You can't just do a nice page layout and expect the HTML to look like that — just as reflowable EPUB won't. You can do nice doc work that will export much the way you want... but that's a different workflow.
I remain stubborn in that if you want a fixed layout that precisely maps your ID pages, there's PDF. Nothing else is really needed. The HTML-based doc formats are simply not suited to a rigid layout as for print/PDF.
Remember, it wasn't that long ago that there was still a vocal and powerful faction screaming that HTML should never, ever, never, never be constrained to a fixed format, but be forever as fluid as liquid helium. It wasn't until those greybeards got out of the loop that HTML/CSS developed significant, robust structural elements... but it's still not suited to rigid page definition because it doesn't have the foundation for it.
(And my beard may be gray and I may have been working with HTML since it was first introduced, but I had too many exasperating arguments with the "fluid forever" crowd who reminded me of parents who think children should never be told 'no.' 🙂 )
Oh, I agree with you. I've switched to Godot (an open source and free game engine) to convert FXL projects and it allows me to export pixel-perfectly to Web Assembly or to an app. The FXL ePub format's scope for animation and interactivity is severely limited and clients just want more.
It takes a bit more time to set up, but there are no frustrations related to possible feature requirements and publishing. It just works.
Of course, the drawback is having to learn another app. But I am also a indie game developer, so it is not an issue for me.
I'm envisioning some extremely bulky HTML/CSS code here. 🙂 After all, Word will do pretty rigid web export, but at the cost of some of the worst, massively convoluted and bloated code I've seen for any purpose on any platform.
What does a game engine have to do with document conversion, though?