Search function not working on fixed layout epub

[NIRC]

For some reason, the search function does not work on several of my ebooks made in fixed layout format. I tried regenerating them, but the result is the same. When I open some ibooks on my iPad (with a promo code, so it's official),  I can scissors-and-paste text ok, but I just cannot search it. This is a major headache... and only happens on some books, even though they were generated from InDesign with the same settings.

[James Gifford—NitroPress · Accepted solution]

Functions like search are about 95% the responsibility of the actual EPUB reader; as long as the text is in the book, the search function should be able to find it. That you can select text means a number of actual document issues probably aren't involved.

I am not really clear what you mean by 'a promo code making it official' but e-books should be thoroughly tested before they are uploaded for distribution and sale; finding faults in a copy downloaded as by a purchase is... not a good thing.

I suggest you try viewing the book(s) on a more generic, standardized viewer, directly from your created files. Thorium Reader is perhaps the best as far as being a "vanilla," standards-based reader; Calibre (just the reader) is a good second choice. The Apple reader is in a separate category of readers with non-standard, proprietary approaches, and is not always the best option for proofing new books or resolving any problems such as this.

Check your books in Thorium or Calibre, and we can take it from there.

[NIRC]

Thanks for the reply. In both Thorium and Calibre, the search function works. However, it does not in Adobe Digital Editions or on my iPad.

[James Gifford—NitroPress]

Just for the record, ADE is an abysmally bad EPUB reader. Nothing it does can be used as an example of either correct or faulty function. And the Apple reader, as said, has a number of proprietary quirks that make it problematic when proofing or testing standard EPUBs.

That the search works on two very standard readers is puzzling, though. Fixed-layout EPUB has a number of limitations and problems of its own, but the only thing I can think of, without seeing the actual file or having you check a number of things, is that the content in it is not in a single text flow. Having a single text flow is absolutely essential for proper reading etc. of reflowable EPUB documents, and while fixed (FXL) EPUB can be more tolerant, if you have the content in multiple flows and broken up among multiple text frames, the search feature and others depending on the document organization might be compromised.

Does the InDesign document have a single content flow containing all text? With, ideally, all graphics, tables and the like anchored to correct spots within that flow? (Again, this is essential for reflowable, but still a good idea for fixed layout.)

[NIRC]

You have successfully located the problem, and it seems to be an Adobe bug. When InDesign created fixed-format EPUB files from a Book containing multiple files, it fails to make it searchable. I will report this to Adobe in the proper forum.

[James Gifford—NitroPress · Accepted solution]

I won't say this is wrong, but I'll make two observations: the fixed-page format is limited and problematic in many ways, and should only be used for very selective projects (primarily "art" books where the page images are more significant than the text). Many aspects of EPUB are less reliable and less 'functional' with FXL export. This could be another.

I am, however, having trouble figuring out where the bug would come in, as the EPUB export creates absolutely nothing to do with searching (no index, no keyword file, etc.) The search function is entirely based on the reader, which searches the XHTML content files for matches. Unless something has changed, you noted that searches worked on the vanilla/standards-based readers, but not on two nonstandard readers (ADE, which simply should not be used by anyone for anything, and the Apple reader, which has a lengthy set of quirks to suit Apple's preferences). That does not point to an integral ID flaw.

I'll also note I've never before seen the problem reported. It seems if there was a systemic flaw here, someone else would have run into it before now.

I'll have to experiment (and first, I'll have to find some material to export to FXL, which I never use), but I'd say the odds are that the bug has little to do with ID's export. ID does have its quirks and limitations, but again, there's no technical basis for an otherwise valid EPUB to be un-searchable.

You might run your examples through a validator like EPUBcheck and see if the two variations show any significant technical differences. (I don't think much of validators for exported EPUBs, but in rare instances they can spot structural glitches.)