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. 

[Cari5FE0]

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.

[Laura Brady]

This is sketchy advice, James. Page navigation is a terrific and mostly benign thing to add to an EPUB. Users who don't understand it might do a little research on the DAISY Knowledge Base to see how useful it is to a variety of readers. Additionally, please use the accessibility metadata panel!! It is absolutely keeping up with the changes — in fact ID20.0 took away some deprecated items and added some new values. 

[James Gifford—NitroPress]

Okay, you made three drive-by comments in this general topic, so I'll address them all here.

I am a practical e-publication advisor/practicioner, not a technical or theoretical one. The problem in each of the three threads you visited is that a particular sales portal (Ingram in all of them, IIRC) was rejecting EPUBs created with the new-to-ID page navigation turned on. This feature and all the added accessibility control came with v19.2-19.4. While it may be Adobe finally bringing these aspects of EPUB creation into liine with the standards and the evolving accessibility rules, the changes also created EPUB files that were not usable in the commercial world.

So in pursuit of the practical goal of getting an EPUB into a distribution channel, I recommend/ed disabling the new feature.

This is not a stance against accessibility, by any means. But the EPUB world is a fragmented mess of implementation, from a hundred readers that don't quite show books the same way to ever-more-elaborate and fussy standards to a panoply of tools and creation platforms.... to a number of seller/vendor platforms that don't necessarily stay in step with all the other changes.

So as much as I applaud those who develop things like the accessiblity standards and champion them, saying book developers should just write off Ingrram or D2D or Kindle or any other vendor stuck in an earlier era is highly sketchy advice from another direction — so disabling accessibility features that are not widely accepted by validators is a practical step.

I also strong discourage and deprecate any practice of editing created EPUB files, so suggestions that ID users should whip out Sigil and delete this or that structual line are even more sketchy in my book.

If an EPUB file is valid according to the standard validators but rejected by, say, Ingram.... do I need to point out who's wrong here, and should be encouraged to evolve?

[Laura Brady]

Hey James. I'm sorry if I have somehow offended you, that was not my intention.  I make ebooks every day and have done so since ebooks were a thing. I am also an accessibility expert who is part of a small group engaging directly with the InDesign engineers to improve the EPUB export. My participation in these forums is peripatetic at best and I hope to get better at that. While I always edit an EPUB post export, my goal is to improve the general EPUB export so that the creators who don't want to fuss with code are still producing ebooks that are as accessible as possible. 

Ingram and CoreSource are not rejecting ebooks made with accessibility metadata and a pagelist. It must be another vendor? Amazon also ingests EPUBs with both without any difficulty.

Allowing InDesign to create page navigation is now a fully mature implementation. It is accepted everywhere. 

The only outstanding bug re: pagelist is external to InDesign. InDesign exports the sources ISBN as: <meta property="pageBreakSource">urn:isbn:9781000000000</meta>. Ace by DAISY will report this as an error at present because it is looking for the older way of marking the source ISBN — that is, <dc:source id="pg-src">9781771669108</dc:source> — but Ace will be updated very soon.

[James Gifford—NitroPress]

No offense at all, and it's good to see another EPUB creator here and contributing!

If you go through the threads on this, most are a case of a specific vendor rejecting submissions, often after v19.2, and turning off Page Navigation cleared the blockage. I'm sure the various vendors evolve — slowly (I mean, even KDP does!) — and the changes in the standards and the rise of things like better doc structure, conforming navigation etc. and accessibility will be accommodated. Book creators should keep trying, using accessiblity settings and good practices... but if the option is waiting until a vendor evolves or publishing a less than technically impeccable book, I'd lean towards the latter.

As I said, I am very much a practical mindset, not a resolutely standards-conforming or technically rigid one.

I'll note to include Page Navigation on future book submissions. It's always frustrating when the big/key players aren't quite on the same, uh, page and we have to work around their faults or stay stuck on an island of righteous conformity. 🙂

[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?