The wonderful odyssey of publishing to Apple Books (possible issue with hyperlinks creation)

I'm not really sure that the depths of this long, specific topic is the place to put a more general argument, but here we are. Actually, it fits well (although it might be overlooked by many forum participants) in that it directly addresses the OP's situation, which started with a technical issue of hyperlinks but evolved into a general problem with the difficulties of trying to please every whim and quirk of every EPUBlishing platform.

The EPUB 3 standard is over a decade old... and no one, in real terms, has implemented it with any rigidity. Every reader, every tool, every publishing platform interprets and bends it to suit what is often the whim or idea of one developer. Consistency across any two readers or platforms is almost nonexistent. So I argue that to try and hew to narrow ideas of technical perfection at the file level is... not useful. I've compared it to the process of 'blueprinting' a car's engine when rebuilding it; it might make the builder feel good and give bragging rights at the concours, but it doesn't really make the car run any better.

EPUB is a victim like all those standards that have no real controlling body or enforcement, thrown into public use for the interpretation of individuals with specific niche needs. It became the central choice of the vast author/publisher world, whose chief goal was to make e-book publication easy for a non-technical, largely amateur user base. In making EPUB creation and management "easy," a myriad of developers has each gone their own way with almost every detail, emphasizing one aspect over others and creating a complete mess of only loosely compatible tools and formats.

Making it worse is that the e-book world — authors, publishers and readers — has been presented with too many formats from too many sources, and both tried to accommodate them all and gotten lost in petty squabbles about which one was "best" or should be used exclusively or — the opposite — should be simply converted at will to anything else as the situation dictated.

So even at the "professional" level, there are no really good, dependable tools or even standards; we have to choose to produce EPUB documents to an independent, internal standard (as for a corporate or technical library), or try to meet the varying demands of five or six primary publishing platforms (Kindle, iBook, etc.) It's a huge PITA.

My chosen goal, beginning a few years ago, was to promote a professional approach to EPUB development. This means, however autocratically, to get the field to grow up and put away childish things — to stop insisting books must be available in or convertible to MOBI and obsolete Kindle formats ("just because"), to stop using outdated processes and techniques (no matter how "easy" they have been for Word authors) and above all, to stop using a collection of freeware, jack-leg, idiosyncratic tools to create and manage EPUB (no matter how many otherwise sincere developers have mastered their process).

Writing, publishing and printing are three completely different processes—and it's the same for e-books. Writers should not be using "technical assembly" tools. Publishers should not be concerned with technical optimization of file formats. "Printing" to a specific e-book platform should not be obsessed with either of the above tasks or pointless optimization of submission files, only in getting a polished result on that platform.

InDesign does not create perfect EPUB files. So what? There is no better, more professional tool for creating publications, and while it's not the best writing tool, it's okay at writing and editing, and absolutely without peer for document organization, formatting and structuring. I've used it for at least four or five years to create both EPUB and Kindle documents, and other than the advanced techniques of CSS optimization I have documented and written about, it's suited every project from simple flowing text to a very complex textbook-like conversion. I'm working on yet another fairly complex book for dual-format publication when not ranting here. 🙂

My suggestion to the field is that Word is the proper tool for writers (in pretty much every field and subject) and can be used to directly create simple EPUB and Kindle books that are not much more than chapter headings and text formatting. For everything else, ID can handle it, and export directly to an acceptable, "press ready" EPUB. Yes, from there you can 'raise the hood' and tinker and streamline and optimize and compress... but only to satisfy some need to make the file structure "perfect" according to a standard no one follows closely anyway. There's no point. Even the most technically perfect, optimized EPUB is going to be subject to whatever reader the, uh, reader chooses... and the majority of them are the quirky, one-author, let's-try-this crap I mentioned above. The same for 'validation' tools; there's not much point in validating a structure if it already works in the final phase of EPUB reading or Kindle conversion.

I suggest that the professional approach is to focus first on the writing, second on the "publishing" aspects of editing, formatting and structure... and leave the "printing" to EPUB export and then any necessary import/conversion to a final platform format. There's simply no need to detour through the complex tools that can tinker with the guts of the file format. The only reason these tools and techniques exist are for that largely amateur/author "hand assembly" crowd, building EPUB documents like a Lego model, where many mistakes can be made in technical structure, cross-references, TOC etc. and need to be validated/fixed in a second step. Although glitches occur in Word and ID development, they can (and should be) fixed at the creation level, not in later rebuilding.

And when there are no glitches, EPUB from either Word or ID works perfectly in the only two "validators" needed: The Thorium Reader (the only one that conforms to my overall argument of a complete, professional approach, not random ideas of reader convenience), and Kindle Previewer. If an EPUB reads perfectly in Thorium, you're done. If an EPUB converts to Kindle perfectly, you're done. Whether or not that EPUB file is as technically, arbitrarily "perfect" and of the very smallest file size or not.

E-Book creation is where web authoring was ten or so years ago: still stuck in a mess of conflicting approaches, whims of individual tools and developers, and trying to please a large crowd of amateurs and users (and publishing platforms) who each have a method and think it's the perfect solution. My goal is to drag EPUBlication into the Dreamweaver era, with a defined methodology that is focused on professional development with consistent results... and not using a patchwork system of random, freeware and often outdated tools and format conversions to get there. Even if the results, the files, are not concours-perfect under the hood. Yet.

Part of this process that's immediately relevant here is to keep kicking Adobe to fix, expand and update the EPUB export process, to the point where ID exports never have glitches, complex demands like the OP's here can be accommodated, and — just maybe — a new tool, optimized for EPUB creation and management using a consistent, professional and standardized approach, a "Dreamweaver for EPUBlication," comes out of the Labs.

I think we also need an EPUB 4 standard that is the equivalent of HTML 5 — bringing years of misdirection and undefined aspects into a tight, modern, framework.

Still awake out there? Class dismissed. 🙂

—

Honest answer? I avoid publishing to Apple Books and advise my clients similarly.

But I'm sure that's an unpopular position, surrounded here by Mac users. 🙂