View Single Post
Old 11-19-2014, 04:32 PM   #17
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 7,602
Karma: 5433388
Join Date: Nov 2009
Device: many
Hi Jonathon,

Quote:
Originally Posted by JonathanMagus View Post
J

The original contained two different contributor roles in addition to a creator role in the .opf file. In the ePUB3 these were replicated with the same ID (refines="#contrib0"), so came up as an error in ePUBcheck.
Yep, that's a bug I will fix that in the next release.

Quote:
Something odd about the generated nav.xhtml document. Unzipping the ePUB3 file there it is called nav.xhtml, however, it doesn't open showing content in an editor (Bluefish). Accessing the file without unzipping shows jumbled errors in the ol tags of the nav.xhtml file and the same is reported by ePUBcheck. Opening in ViewPorter (a Sigil clone?) shows the mark-up, however, says it is called toc.xhtml, although that may be a quirk of that particular software.

Anyway, the point here is that the ordered list in the TOC doesn't come out right after the conversion.
I can not recreate your issue with a valid toc.ncx file. So can you please post (or pm me) with the toc.ncx (from Sigil) for an ebook that ends up with a messed up nav.xhtml. The created nav.xhtml is called is "nav.xhtml" not "toc.xhtml" and will be found right beside the content.opf file, not in the Text folder.

Quote:
Also, the toc.ncx was retained in the ePUB3, however, registered an error with ePUBcheck because of the DOCTYPE. Not sure if that is correct or not.
That is actually a bug in epubcheck3. You need that valid doctype for fallback on epub2 readers. There is a bug fix for this in the epubcheck4 (alpha or beta version?). You can find the bug report that discusses why that DOCTYPE can not be removed on the official idpf website.

Quote:
Do I understand correctly that Sigil will become ePUB3 compatible in a future release? It would be fantastic if it does. I have been discussing making Bluefish, which toggles well with Sigil, more ePUB3 friendly for detailed editing of component files recently and perhaps it would make sense to coordinate this?
That is the plan. We are experimenting with ways to replace Tidy (and its limitations) with an embedded python version of html5lib and beautiful soup4), to create a much more robust environment for poor html, then breaking off flightcrew into a plugin, and starting on support for epub3 metadata, opf, etc. This is a major undertaking that will take some time, which is why I threw this plugin together to create a stopgap mechanism for epub3 authors while we make all of these changes.

Take care,

KevinH
KevinH is offline   Reply With Quote