epub validation error

[karenb27703346]

I am getting the following error when trying to validate a reflowable epub that I exported from InDesign: ERROR(RSC-012): epub/OEBPS/toc.xhtml(63,94): Fragment identifier is not defined.

Nothing I try is getting rid of the error. I've tried rebuilding the TOC in multiple ways. But it is not fixing the issue. 

[James Gifford—NitroPress]

Have you 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.

Try deleting any TOC panel you have (and note that a visible/page TOC is something pretty much deprecated in e-books), tidying up your TOC definition as needed — don't forget to save it under a unique name, don't use [default] — and re-create it.

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.

[Shanpub]

Hello, @karenb27703346  Use Sigil to open your ePub file and look for line 63.

If you can, send us a screenshot of the file.

This is simple error

[karenb27703346]

I opened it in Dreamweaver since I don't have Sigil. Here is the screenshot. 

[karenb27703346]

The only solution I found to this problem was to export it as an Epub 2.0.1 rather than Epub 3.0.

[James Gifford—NitroPress]

That's a bit like printing something in grayscale to fix a color problem.

Did you work through the steps above?

[karenb27703346]

Yes, I did. And nothing worked to remove the error. I know it is not ideal, but I was on a time crunch. And since none of the other solutions worked, I went with what did work. 

[James Gifford—NitroPress]

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.

EPUB 2.01 isn't much of a solution, though. It really shouldn't even be an export option any more. It's likely to cause more problems down the road than solving this one validation error is worth.

[James Gifford—NitroPress]

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.

That would point to the location/source and possibly cause of the faulty content, and it can be corrected in the source file, probably by deleting a dead or broken TOC anchor.

[JKunkel99999999]

I'm getting a similar error message: "(RSC-012): /OEBPS/toc.xhtml: Fragment identifier is not defined."

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."

The first page worked if I switched to Georgie type (which is a TT type). But if I added a second page with the same sentence, I still get the above error message. 

So far, I don't know what to do!

[WritelyDividedEditing]

Did you find a solution? An ePub I created for a client is generating the same problem: it uploaded to Amazon with no issues, but comes back with the RSC-012 Fragment identifier errors for Ingram Spark. I don't know where to start. I only use InDesign and am not familiar with Sigil, etc. 

[James Gifford—NitroPress]

You shouldn't need to edit an exported EPUB for any reason.

I don't remember the whole of this thread, but start with this: under the EPUB export menu, is "Page Navigation" unchecked?

[WritelyDividedEditing]

I ran an ePub 3.0, and it uploaded just fine to Amazon. Page Navigation on that file -was- checked. Should it be unchecked? 

[James Gifford—NitroPress · Accepted solution]

Yes. It's a new feature (implemented in v19.2 or v19.5) supporting a form of accessiblity that is not fully cooked yet and is not universally implemented; Kindle simply strips it out, but many other EPUB vendors see the code it adds as a flaw. Don't check it, ever, until and unless you understand the accessibility it enables, need that feature, and the vendors have slowly caught up to the new standards and features.

Also stay out of the Accessiblity menu (a submenu of the Metadata export pane) for all the same reasons. Accessiblity is good, but it's an evolving area of EPUB and the industry is not entirely in step with the changes, and it's not clear if ID's implementation is completly conforming.

[WritelyDividedEditing]

Thank you very much for the quick and kind explanation. I have sent off the file with Page Navigation UNchecked with big hopes that it solves the problem for my client. 

[Cari817]

I followed this suggestion and it seems to have worked. I got back no errors when I uploaded the EPUB to IngramSpark. Thank you! I was at my wit's end.

[James Gifford—NitroPress]

Glad you found it. It's one of those disconnected errors that doesn't really leave any trail to its cause; only by digging into the code and working backwards through the accessibility changes can you make the connection. With any luck, Ingram et al. will upgrade their validation to include these new components of the standard and it won't be an issue any more.

[Abhishek Rao]

Hi @WritelyDividedEditing,

I understand how frustrating it can be to deal with EPUB validation errors, especially when your file seems to work fine in some places but not in others.

To help troubleshoot the RSC-012 Fragment Identifier error, could you please provide the following details?

1. What version of InDesign are you using?
2. What operating system are you on?

Additionally, it would be really helpful if you could share a screen recording of the workflow where you’re encountering this issue. This will give us better insight into the problem and help us provide a more accurate solution.

Looking forward to your response!

Thank you,  
Abhishek Rao

[WritelyDividedEditing]

I am using InDesign 19.5 on a Mac. I ran an ePub 3.0.
Here is the error message my client received on uploading the ePub to IngramSpark. Apparently, there were many more lines of the same error that she didn't screenshot. There was no problem uploading the ePub file to Amazon. 

I am resending her the file with "Page Navigation" unchecked this time instead of checked to see if that makes a difference. 

[James Gifford—NitroPress]

Besides creating extra TOC elements, the feature adds page-break code to the entire document, with the notion that it enables print and e-book users to literally be on the same page. Good idea, currently breaks most of the validators and vendor approval systems.

It should be self-evident that the problem is not being handled the same by both KDP and Ingram, so that's not any important point.

[delehman]

Same error on loading to IngramSpark: (RSC-012): /OEBPS/toc.xhtml: Fragment identifier is not defined.

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?

[James Gifford—NitroPress]

For both @delehman and @JKunkel99999999 — EPUB can be fussy about TOC elements, never more so than when you try to omit one. There's a regular error in FXL EPUBs where selecting "None" for the TOC, even if that's sensible, leaves a tag end in the TOC file that many book portals dislike.

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.

Not at all sure if the fault lies with ID or inconsistent interpretation of its idea of an empty TOC. Many of these files seem to pass validation but not upload to one book vendor or another.

[delehman]

Thank you. I suppose it could be a change in Ingram's validation, too. I'll give it a shot, although I'll probably have to muddle through the steps, never having done a TOC this way beofre.

[delehman]

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.

[delehman]

Oh, and exported to reflowable epub using the multi-level option with the EbookToc style selected.