The Broken Beginning - Part Two Epub

[Barbara Fillmore]

Haveyou deleted the TOC and re-created it? If you update a TOC frequently while editing, it can leave broken/orphaned anchors in the text, and ID will export them. They're harmless grit, for the most part, but validation will flag them.

If, properly, your TOC is only for the dynamic e-book one, try creating a new "style" and saving it under a new name, then generate it. (I find it useful to actually place, then delete the text frame containing the TOC; not sure if that's necessary but it assures me TOC generation is completed.)

If none of that works, you will probably have to clean out the source file: export to IDML, then open that file and save as INDD again under a new name. That purges leftover/junk data like lost bookmarks and TOC markers, and rewrites the INDD structure to remove corruption. Then generate your TOC anew and you should have no further problem.

Okay. TOC errors per se are not usually that hard to correct, and those steps should remove any leftovers or faulty bits from prior TOC generation. The solution would be to search both the source and generated files for markers and delete any that are not part of a current TOC, which is tedious.

The most focused method for finding the problem is probably to extract the toc.xhtml file from the generated (and validated as faulty) EPUB and review it for a broken or incomplete link. There should be an obvious discrepancy between valid links and one or more faulty ones, although it may take some time to review and compare the lines to find it.

I loaded my ebook to Amazon with no problems, but when I try to upload to Ingram Spark I get the above error message and am not able to proceed. After several trys, I stripped my book down to 2 pages - Neither of these 2 pages contain any TOC links. They're both just one sentence - "Mary had a little lamb."

I don't have any TOC information set up in my ebook. (And I don't include a TOC in the print book.) I build the ebook TOC from file names, not from internal information. I've never encountered this issue on my previous books, and this is my 11th. Has something changed in a recent ID release?

I'd suggest generating a dynamic TOC, under a style name EPUB or EBOOK or the like, even if it's essentially empty or null, and assigning it to the export using the Multi-Level option. That's the only thing that seems to provide a proper stub or "empty" dynamic TOC.

Nope, that didn't work. I still get the errors. I created a TOC called EbookToc, using my Chapter Heading style. I checked "Include Book Documents." (I have a book with separate documents for each chapter and for verious front/back matter). I also syncronized the book documents. I'm not sure if that's needed, but it can't hurt. When I import the resulting epub into Kindle Previewer, it seems to have build the TOC correctly, but the import to Ingram still gives the errors.

I lean towards it being an Ingram issue, but not with any confidence. The whole field is in churn right now, as the new accessibility standards are being implemented by some players (InDesign, EPUBcheck, etc.) but not by all. It's not that either party is wrong, just that validation and doc checking and such is out of step.

I think I see the problem. In toc.xhtml, there is a section called "Page List." Under that, there are links to pages within chapters. The IDs on these links are of the form "Chapter_X.xhtml#pageN", where X is the chapter number and N is presumably a page number within the chapter. Inside the chapter files, there are page break elements that have IDs, some of them of the form "pageN" format but others of the form "pageN-M" where M is a number that doesn't seem to make much sense. I supect the latter elements are the ones causing the issue. For Chapter 2 in my book, for example, the TOC links to Chapter_2.xhtml#page1, Chapter_2.xhtml#page2, etc., but the IDs in the chapter file are "page1-4", "page 2-1," etc. "page3" doesn't have the extra number, then "page4-1." So some of the links to the pages are broken, but others are not.

My thought was to uncheck "page navigation" when doing the export., but the page list is still built in toc.xhtml, so the problem is still present. I don't know if deleting that section and re-compressing the epub would work or if that would create other problems. But it seems ID is doing something odd, or I have a problem in my files that causes it to do something odd.

Have you passed the result through EPUBcheck? The raw command line version is best but you can use other versions that wrap that core in an app or website. I just don't care for all the extra "help" and spin and interpretation the latter provide.

I'm actually doing nothing fancy. For the epub, each document contains a single text frame. I don't set up anything internally for the TOC. On the export, I tell it to use the file names for the TOC. It seems to deo that right, but it's messing up on building the page links. I think the page links are something fairly new. I don't recall that checkbox on the export the last time I did this (which was late in 2023). I'm not even sure how an ereader uses that feature.

I did find two places where I had a couple of elements in separate text frames from the rest of the document. I know that can cause problems with the display order, but in the past it's never had this effect. Nevertheless, I fixed those and re-exported and got the same issue. I'm under a bit of time pressure right now, so I probably will have to manually fix the xhtml files if I can. Not ideal, but it's at least an option. Thanks for your input, though. I do appreciate it.

I'm not sure File Names is a reliable TOC method. And while extra text flows are not usually a problem (except that they can be left out of the export, or fall to a random order at the end), they should be removed. EPUB really works best with completely clean, linear source files, and adding a book structure if it's not needed is a contrary idea.

ETA: if you aren't using Multi-Level for the TOC model and defining/generating a simple TOC as outlined, all bets are off. I am not sure the other options are compatible with any platform; I have notes to the effect that File Name should be avoided but I can't quire remember why.

Huh. Well, you probably have a deeper undrestanding of I than I do. All I know is, for my first 10 books, file names worked just fine. Now suddenly they don't, but neither does multi-level TOC. Both methods seem to generate the same thing. I'll keep fiddling with it and let you know if I get anything to work. My only advantage is that I'm a software developer and understand xhtml files, generally speaking. But I'm not an expert in epub format. Not yet.

Knowing HTML/CSS is a huge advantage,. but the structural "glue" of an overall EPUB file is... not nearly as linear and sensible. And the lack of any enforcement of standards means that the field is chaotic, as well. In many cases, it comes down to the old "compiles... first screen comes up... ship it!" level of validation. (I have some time in software as well...)

So...I got the ebook fixed, but not the exporet problem as yet. The solution was to use Calibre to edit toc.xhtml and delete the page navigation section. Then it works fine for uploading to Ingram and displays fine in both Calibre and Kindle Previewer.

After poking around a bit in the files, I think you're pobably right that the problem is related to exporting a book. It looks like the pagination stuff is built assuming that it's all one file, so there can only be a single page 1, page 2, etc. If it finds more (treating each doc in the book as a separate entity), it appends a number to distinguish them, even though that's not actually necessary, because the tags are in separate xhtml files. This must be related to the new Page Navigation feature. Problem is unchecking it does not prevent these tags from being generated. Maybe one of the other options you mentioned would do that, but I'll play with that later. Thanks again for your input. There is a bit of light at the end of the tunnel now. (And with luck it's not an oncoming train!)

Not quite sure we're on the same page, but multiple content files are common. Best to have a single one, but multiple text flows and/or defined splits will create multiple ones, sometimes dozens. Nothing to do with the accessibility changes. If you use multiple articles in an ID doc, or a Book, you'll get one XHTML file per text flow.

To explain better, I have an .indb file. Within that, there is one .indd file for each chapter, plus a few more for front and back matter. I set up my print book first, then I copy those files to a new folder, create a new .indb for the epub, and add in the copied .indd's. I then do such formatting changes as are required (non-breaking spaces, etc.) to make them display correctly. In the print version, the chapter headings are in a separate text frame from the body of the chapter. In the epub version, I move the chapter headings into the main frame. I sometimes use small graphics to separate scenes. These are all in-line in the text frames for the epubs. That's about it. I try to keep it as basic as I can, especially for the epub version.

The blue arrows are pointing to Garamond Italics that have all spaces between words eliminated. There are other fonts used for captions, titles, subtitles, and other things that are also problems, but these are the easiest examples to see and I hope that clearing up these problems will fix them too.

Hi Derek, I have not completely figured that out, but I am thinking for the electronic version that I can split it into three smaller books. Although, I would like a version of the whole thing. Currently, this problem is occurring when I try to epub just one chapter of 32 pages.

Also give reflowable EPUB a shot, just to see if the outcome is first-pass acceptable. You might want to explore that route if it is; it's a lot easier to tweak the output and balance out problems. Don't use embedded fonts, though, or even defined ones. E-books are not meant to be a visual representation of a printed page and you'll avoid a whole cascade of problems.

3a8082e126