Epub footnotes links formatting

[Elesa384956462t1z]

It is possible this has been answered elsewhere, but I'm not even sure how to search for it. When I exported my epub, I was happy to see that my footnotes at the end of every chapter already included a link to return to the main text where the footnote was---it has duplicate numbering, but I'm not as concerned about that as I am about an issue with the formatting of these links back to the text. I don't know why, but some of them are showing up as bigger text with a paragraph return after them. I honestly can't see any difference in the way those footnotes were formatted. Do you think this is a styles issue? A footnote settings issue? Any thoughts?

This formatting issue shows up in every one of the readers I'm using, by the way.

[James Gifford—NitroPress]

Export of notes to EPUB is a fragile and fussy step. Without knowing the nuts and bolts of what you've done to create this numbering system, I can't address any simple specifics. As footnotes (should) inherently be bidirectionally linked in EPUB, try removing all your extra numbering and formatting and see if the basic model works for you (and exports properly).

I largely dislike how footnotes work in EPUB/Kindle readers and place them inline, but that may not work for your project.

[Elesa384956462t1z]

Yeah, I wasn't prepared for how fiddly it might be. I actually haven't created any extra numbering, these are just the basic model, basic functionality already. But maybe it is because I set it to restart for each chapter (section)? It is strange that the linked footnote numbers are not restarting in each chapter, but going continuously.

[James Gifford—NitroPress]

Okay, I assumed the odd double numbering was something deliberate and thus possibly a factor. If the three digit numbers with the varying formatting aren't... intended, what are they?

Basic question: what EPUB viewer are you using to review this? They vary considerably; the most neutral, standards-compliant one is Calibre. I recommend using it, or Thorium Reader — a theoretically more standard reader, but it has a font-size bug that can confuse things — as your base proof tool. All others apply their own quirks and faults.

Then, try purging your source file to fix any corruption or broken links. Export to IDML, open that, save as INDD under a new name. That often rewrites a file structure and fixes both corrupted elements and "links" of all kinds within the file. Try the export from that, in a 'vanilla' reader like Calibre, and see what happens.

[Elesa384956462t1z]

I tried your solution, but it is still doing the same thing, for some reason. I have no idea what the double numbering was from, since I didn't actually manually create any numbering, just used automatic footnotes. However, I just fiddled with the epub export settings, changing the exported placement setting of footnotes to pop outs instead of end of section. For some reason, that got rid of the double numbering. But the formatting issue still remains. And now, when I click on the footnote, the pop out is blank on those weirdly formatted numbers, like the 3 footnote you see below. By the way, yes, I am using Calibre (the screenshots were taken of the book in Calibre), but I also always check in Google Play books and Kindle Previewer, since using all three tends to help me find the bugs a little better. By the way, I really appreciate your help! I realize this might not be fixable without messing with the code, but I'm just hopeful!

 

[James Gifford—NitroPress]

Okay, well, two things — anomalies like the double numbering aren't things that can be ignored as symptoms of something quite wrong with the document and export process., and work at the code level should not be needed to resolve this.

When export with notes works, it works seamlessly and without faults. If there are faults, they lie in the document structure and they should be fixed even if some hack or workaround is discovered — especially if the fix is to edit the exported EPUB to fix broken code.

That is: all of this can be avoided in most projects, can be fixed when it's encountered and should not need extraordinary measures to repair. 🙂

It looks as if the problem is formatting in the notes themselves. To what extent you can, go through the notes themselves and reset each to a vanilla, base paragraph style. Get rid of all spot formatting and character style applications, and be sure to remove any soft returns (a fairly recent discovery as a source of note breakage). When the notes, including their number/link, are completely purged of formatting above the base paragraph style, try the export again. Actually, try the IDML to INDD to EPUB circle again, to let ID clean up any broken bits from misapplied formatting.

[b52bubba]

I have the exact same problem: Reflowable export results in some (not all) endnotes having large endnote numbers followed by a line break then the period and the endnote text. I'm using ID 19.5. The problem is visible in Apple Books and Calibre. I have an indb with 13 indd chapters and many of the chapters (not all) have some (not all) endnotes formatted problematically as I describe above.

Things I've tried that haven't worked (and to save you the time...NOTHING has worked so far):

• Exported .indd to .idml as new name, opened in ID and saved as .indd with new name
• Yes, yes, yes--my endnotes all have the SAME para style with no character styles
• Deleting the troublesome endnotes and redoing them

I've identified the technical problem in Calibre by looking at the html/css, and I know I CAN fix each  endnote in a 700-page book by manually removing the wrong code in smippet 2 below (causes the problem) and making look like snippet 1 (formatted endnotes correctly) but I only have so many years left.

Snippet 1 (this code correctly formats my endnotes)

                  <li id="footnote-016" class="_idFootnote" value="3"><p class="p"><a class="_idFootnoteAnchor _idGenColorInherit" role="doc-backlink" href="Chapter7ChapterName.xhtml#footnote-016-backlink">3</a>. See Author Name, <span class="CharOverride-2">Book Name</span> (City, ST: Acme Publishing, 2016), chapters sixteen and seventeer.</p></li>

Snippet 2 (the problem is due to the red text)

                  <li id="footnote-015" class="_idFootnote" value="4"><div id="page5-1" role="doc-pagebreak" aria-label="5" epub:type="pagebreak"><a class="_idFootnoteAnchor _idGenColorInherit" role="doc-backlink" href="Chapter7ChapterName.xhtml#footnote-015-backlink">4</a></div><p class="p">. For example, Program1 with Founder1 and Program2 with Founder2.</p></li>

Any help appreciated for solving this in InDesign. What's SUPER frustrating is I've exported many EPUBs from ID before and never encountered this.

[b52bubba]

I solved my own problem--sorta??  In my InDesign EPUB export dialog box in the Text section, I UNchecked the "Remove Forced Line Breaks" checkbox and my endnotes are all fine now. 6 hours of my life I can't get back due to this non-sensical "feature." that somehow INSERTS a line break between some endnotes and triples the font size. Sigh.

[James Gifford—NitroPress]

Interesting — we'll have to see if this is a universal cause/fix. I think there have been only two reports so far and I haven't been able to replicate the problem, so hopefully the next person who encounters the issue will find this thread and report back.

The question here is: do you have deliberate soft returns in your end notes? One thing and another is showing that to be, if not bad practice, then at least something to avoid in ID footnotes and endnotes. Extra paragraphs and soft returns seem to confuse the export process.

[b52bubba]

James (I really value your book--it's beside me now). I don't have any soft returns. I always show invisible characters and confirmed I have no returns--and definitely not between the endnote number and its period. Thank you for being so responsive.

[James Gifford—NitroPress]

No problem, and thanks.

I'd say it's in the category of ID export bug, then. I need to set up some test files.

What was the complete source path of the component chapter files? Word? Something else?

ETA: I have run a series of tests on a simple document, changing up all the settings for both foot and end notes, and can't replicate the fault. (General question): is it only with ID Books? (I'll fudge one up and see, but all reports welcome.)

[Elesa384956462t1z]

I know it has been forever since I responded, but I just wanted to give an update in case it is helpful for future users. I also didn't have any line breaks in the doc. I did a find and replace just to be sure. By the way, this issue shows up in every reader I use, including kindle, google books, calibre, and apple books. And the original document was a Word doc that I placed in InDesign.

I ended up converting all my footnotes to endnotes, and that solved the problem (which does suggest a formatting issue?), though it meant I couldn't do the notes as popups since that isn't an option for endnotes. Nothing else that was suggested here worked (I literally got rid of all my styles as a test, putting everything as the basic paragraph style with no character styles applied, etc.). However, I just tested the fix suggested above and unchecked the "remove forced line breaks" and it worked! Crazy.

[James Gifford—NitroPress]

Thanks for the followup.

The footnote/end note problems with EPUB export, almost always originating from a Word import, are maddeningly elusive. I have only encountered them when I develop a corrupted InDesign document, with that and other problems cured by the IDML export and reopen. There does not seem to be any single, consistent reason for the more persistent failures and every time it's run down to a fix, the details and fix are slightly different.

My working theory at this point is that InDesign's handing of notes, after they are inserted, is all but passive; when further operations like exporting are done, ID just packages up what's framed as a note element and passes it along. So if there is corruption, or multiple layers of "wrapper" from the various stages, or duplicate numbering, or other faults, they're just written into the destination doc as-is.

I need samples of broken documents to refine this theory, but most users are not willing to share papers, reports, books etc. for fairly understandable reasons.

[William26752773415r]

Thank you! I had the same problem and that worked for me. 

[Optimistic_face6C2C]

THANK YOU, THANK YOU, THANK YOU!!! I, also have spent hours trying to fix this exact issue.  😄