Fixed Layout ePub Exported by InDesign Fails Validation in ePub Checker v4.1.1

[johnc16723100]

I'm using InDesign to make Fixed Layout ePubs. I just upgraded ePub Checker to v4.1.1 and now all my ePubs that had no errors before with v4.0.2 now generate an error. Here are screen shots of the v4.0.2 and v4.1.1 check results:

The error returned is in toc.xhtml: Error while parsing file: element 'ol' incomplete; missing required element 'li'. Here's a screenshot of the toc.xhtml:

The error is at line 9. There needs to be an entry between <ol> and </ol>. Leaving this empty is apparently no longer valid using the 4.1.1 ePub Checker library, but used to be OK with the 4.0.2 library. I contacted the developer of ePub Checker and he said:

This comes from the underlaying validation engine of the official EPUBCheck library.  There has been a minor update as you can see when having a look at the version numbers (4.1.1 vs. 4.0.2).

Core developers made an update to the TOC schema with PR #763 (https://github.com/w3c/epubcheck/pull/763😞

> fixes nav doc validation to be more faithful to the spec

> * require at least one li child for ol

So this is be intention and it seems you have some empty <ol> elements with no children in your toc.xhtml which is not valid anymore.

You have to fix these... so InDesign is not producing ePubs that conform to the current standard. The problem is, that InDesign is exporting an empty TOC with an empty <ol> element if you do not set toc titles properly before exporting.

Note that I'm using the most current version of InDesign (2019 v 10.0.1), and that the ePubs I'm exporting out of InDesign are Fixed Layout, so setting toc titles is not an option in the export dialog. So to fix this I would have to add an li child between <ol> and </ol>.

So starting at line 8 it would read

                   <ol>

                           <li>  ????????  </li>

                   </ol>

Not being really familiar with html and relying on InDesign to produce my ePubs, I don't know what to put here. What should I put here as a work-around to make the ePub valid? Note that the ePubs I now have that validate correctly against the old standard still work fine as far as being able to be read. So the only change is to make the ePub valid – there is really no change in the way the ePub is read or displayed on various devices. Or, the ultimate question: Do I really need to worry about this? Looks like the ePub Checker developers just made a tweak in the validation procedure to conform more tightly with the specs, but will the minor error, which apparently doesn't affect how the ePub is read, cause iBooks and others to reject the ePub? Bottom line, however, is that Fixed Layout ePubs produced by the current version of InDesign apparently do not conform to the current standard.

[Steve Werner]

Moving to InDesign EPUB forum

[johnc16723100 · Accepted solution]

Problem solved! When exporting the Fixed Layout ePub, select "File Name" when setting the Navigation TOC. I had mine set on "None" which was OK when validating the file with the old version of ePub Checker (v4.0.2), but generates the above error when using v4.1.1.

@

[brendanhall2003]

Thank you thank you - you've saved me from humdreds of hours of head scratching to solve this issue...

[julieb64757599]

I had the excat same issue, with my fixed layout. and changing the TOC navogation to file name fixed my issue!

Gosh i love to see a valid epub. Thanks so much.  

[jodig63578603]

Was having the SAME issue, and the SAME error! Thank you; that did the trick!

[swinghouse]

Worked for us too. Thank you.

[Lighthouses For Life]

Thankyou! Thankyou! Thankyou!!!

[iPublishUGlobal]

This page saved the day!  I made the small but significant change to my Epub file, NONE TO FILE NAME and I was able too publish my Ebook. WOW!

Thank you form the bottom of my heart!

  http://www.PalmBeachBookPublisher.com   917-767-5843

The Most Genererous Publisher in the Industry!  10 Day Global Distribution to 39,000 Retailers!

[meadena]

Thanks for that simple solution!! Perfect! Saved me having to try an work out all that coding stuff!

[joo04291978]

Thank you soooo much! I reached out to technical support with this problem and they could not help me. You saved me from many hours of fruitless frustration!

[judithvilleneuve]

Thank you so much you saved my life! Merci beaucoup! My ebook is valid now.

My only question is, it is written : 

INFORMATION (RSC-004) at "Test 29.epub/Test 29.epub":
File "OEBPS/font/BebasNeue-Regular.otf" could not be decrypted.

INFORMATION (RSC-004) at "Test 29.epub/Test 29.epub":
File "OEBPS/font/CooperBlackStd.otf" could not be decrypted.

No errors or warnings detected. EPUB is valid!

Does anyone knows, why the fonts cannot be decrypted and what I can do about that? Is this an obstacle, when I like to publish on Apple Books? Thank you so much in advance! 

[9tailedfoxe]

Thank you so much!  I was circling around in a maze for days on this, with a deadline coming, and your help just saved the situation.  Thank you!

[carla27733456iydi]

Thank you so much! After hours of looking through forums for a solution, this worked for Ingram Spark submission. I kept getting the same error code on their website for my ebook. I guess they use a similar EPUB checker. So, to all other self-publishers exporting using Adobe Indesign, make sure to select File Name under TOC Navigation when exporting your EPUB. It solves the problem right away. Thanks again!! You saved me another two days of ripping my hair out! 

[carla27733456iydi]

Since publishing my last book, I have been working on a new one, where the fixed formatting has not been preserved in kindle. If this happens to you, use the reflowable output for EPUB, and then use the paragraph styles to insert page breaks so your text is not stuck together. 

[Natascha15A8]

Oh my god, thank youuuuu!

[default0khuqg4m14x8]

God bless you, whoever you are! I was ready to screech. all good. thank you.

[doinaparas@gmail.com]

Same here! I wasted 2 days trying to figure it out! Thank you!!!

[Greg Adkins]

I'm using ID 16.3.2. I checkoff -- Make text anchor in source paragraph, which fixed a few things including my TOC navigation for Fixed layout EPUBs. I'm left with two items - 'missing NCX file' and 'submitting an encrypted epub 3.0 file'.'

[Greg Adkins]

Never mind I figured it out. Currently using reflowable.

[MARU.R.]

GRACIAS !!!

[pxSpectrum]

For 2 weeks, I've been working through issues, but to no luck at all. Not sure how to get past this. The TOC option only helped one issue, but the fonts are still throwing errors "(PKG-026): /META-INF/encryption.xml: Obfuscated resource must be a Font Core Media Type (was declared as "application/x-font-ttf" in "OEBPS/content.opf")".

I've replaced fonts to google font alternatives that are "open fonts" but still I getseveral of those errors, without ANY help in that error as to why. I can't find anything online anywere. The issue is clearly InDesign at this point!

Any ideas?

[James Gifford—NitroPress]

It's not entirely useful to tack on a different problem to a 2-4 year old topic — and at that, there are other discussions that have focused on your specific font problem.

Here's a fairly recent discussion of the problem, although it contains no absolute answers. A short overall answer is that FXL is an obsolete format that has only a few narrow useful purposes, is difficult to tweak or fix if the export isn't perfect. that many validation errors it throws have no effect on its actual function/readability in a standard EPUB reader (it's the nonstandard platforms that choke, typically)... and embedding fonts is and always has been a clumsy, complicated, fraught practice best avoided.

Whatever faults InDesign itself brings are, in my experience, largely through not using conventional hacks and workarounds that make FXL work in the nonsstandard tools, format and reader arena. One of those "faults" seems to be adherence to font and resource encryption and rights management; since ID is an Adobe product, it seems to be stricter about what fonts can be embedded, and under what conditions, than the amateur/freeware/nonstandard slate of tools.

The real solution overall is to not use fixed layout EPUB.

[James Gifford—NitroPress]

And just an ETA: validation is one of those processes that is not nearly as absolute or necessary as it once was, or is for other processes where EPUBs are all but "hand built" in structural tools. The real test is to view the document in a standard reader like Thorium or Calibre... and if it renders without fault in those, validation errors are of little meaning.