New Issues in Sigil 0.9.3

[jafprrr]

Hi,

I have recently updated to Sigil 0.9.3, from 0.8.x(?)

When trying to create new epubs as Version 3 (epub3.0), I consistently receive the following errors in each of my uploads to CoreSource that I did not have previously. Some of them (such as the language) are clearly related to the Metadata Editor not having been implemented yet, but others are a little harder to work out:

assertion failed: Exactly one manifest item must declare the 'nav' property (number of 'nav' items: 0).
attribute "opf:role" not allowed here; expected attribute "dir", "id" or "xml:lang"
attribute "opf:scheme" not allowed here; expected attribute "id"
element "metadata" incomplete; missing required element "dc:language"
value of attribute "width" is invalid; must be an integer

Any help in resolving these issues would be appreciated. At the moment, I'm thinking of just reverting back to Version 2 (epub2.0), as these issues don't arise in that format.

[KevinH]

Hi,
Epub3 ebooks require a nav document by present in the ebook and require epub3 style metadata? So you simply can not just change the package version setting? Did you try convert your valid epub2 to epub3 using epub3-itizer? If not, how did you convert it to epub3? There are new epub3 tools (see the menu) to create a nav document from a valid NCX. There is also a tool to properly update the manifest properties to automatically add the "nav" property for the newly created nav document. Unfortunately, Sigil-0.9.3 does not have a metadata gui editor (the next version of Sigil will). So you will have to manually edit the metadata in the content.opf.

A much easier approach if you do not know how to edit epub3 metadata is to stick with epub2, make all of the changes you want, and then invoke the epub3-itizer plugin to convert it all to epub3 for you.

KevinH

[DiapDealer]

EDIT: KevinH posted in the time I took to compose mine. There may be some overlapping stuff.

It sounds as if something overwrote the metadata section of the opf file with EPUB2 metadata. Did you edit the EPUB3 with anything other than Sigil v0.9.3?

Points to consider: Sigil v0.9.3 does not allow the editing of an EPUB3's metadata with the graphical Metadata Editor (as you noticed). Did you manually add metadata to the OPF file in Code View? I only ask because you specify you're creating new epubs as EPUB3s with Sigil: which means there should be no metadata in the opf (other than a dc:identifier), so I need to understand how those metadata elements are getting populated in the first place.

Also, are you adding existing files to the new EPUB3 with Sigil? If so, there's a bug in Sigil v0.9.3 that can cause EPUB3 metadata in the OPF to be corrupted as a result (reverted back to EPUB2). I'll let Kevin answer more definitively, but I would think there would have to be some existing EPUB3 metadata to get corrupted in the first place, though. I could be wrong on that.

If you ARE adding external files to a new EPUB3, you may want to take a different approach until the next version of Sigil is released (in which the bug is gone, and metadata can be edited "normally.")

My recommendation (until Sigil v0.9.4) would be creating your epubs as EPUB2s. Then add whatever files you need; edit your metadata, and when all is well (and validating), use the ePub3-itizer plugin to convert it to an EPUB3. Once you have your EPUB3, do not use Sigil v0.9.3 to add any existing external files or the metadata could get corrupted again.

[jafprrr]

Thank you, all. That's a great help.

[Notjohn]

At the moment, I'm thinking of just reverting back to Version 2 (epub2.0), as these issues don't arise in that format.

I think that keeping one's head down and waiting for the dust to settle is a very good tactic, perhaps so good that it really deserves the name of strategy.

[KevinH]

That really depends on how much hand-holding you need. If you do not know the epub3 standard and do not know about epub3 metadata formats, then Sigil-0.9.3 won't do much for you without ePub3-itizer. If on the other hand, you are comfortable editing the content.opf and understand metadata, Sigil-0.9.3 can be used to create quite advanced epub3 ebooks that do validate correctly.

The upcoming version of Sigil-0.9.4 includes even more bug fixes and a Metadata GUI editor, and will create an empty nav.xhtml for you along with the tools fill the nav in from heading tags (just as done with the NCX). It will also include epub3 Landmark semantics tagging for files in BookBrowser. So more tools will be available for those who need more help in converting their epub2 books to epub3.

Hope this clarifies the state of things a bit better.

KevinH

Originally Posted by Notjohn

I think that keeping one's head down and waiting for the dust to settle is a very good tactic, perhaps so good that it really deserves the name of strategy.

[DiapDealer]

I'm pretty sure that was Notjohn's obligatory "I'm sticking with Sigil 0.8.x" sentiment, rather than a relevant commentary on the OP's primarily Sigil agnostic concerns about EPUB3 vs EPUB2 creation.

As you say though, Sigil has never really absolved anyone of not having to know a single thing about the structural requirements of how epubs are constructed. EPUB3 wil be no different in that regard. There will still be a learning curve for those who don't know the differences that EPUB3 brings to the table (just as there was a learning curve when they learned how to construct/validate EPUB2s).

So it's not really about "allowing the dust to settle," in my opinion. Its about deciding whether you're willing to learn anything new or not.

But like you, I believe the next version of Sigil will greatly lessen the hurdle to creating EPUB3s for the casual user. All without affecting those who prefer to stick with EPUB2. I honestly can't think of a single reason why an EPUB2 aficionado would hesitate to use Sigil v0.9.3 (other than for hardware or OS limitations). At this point, there's very little dust on 0.9.x's EPUB2 abilities in need of "settling." I would call hanging on to the 0.8.x series at this point (other than for the above mentioned reasons) self-deprivation rather than a strategy.

[DNSB]

A couple of minor nits with items in the Tools menu (Sigil 0.9.3, Win10 x64):

The code I use for cover images is:

<div class="svg_wrapper">
<svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 1000 1500" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink"><image height="1500" width="1000" xlink:href="../Images/cover.jpg"></image>
</svg>
</div>

The file cover.jpg exists in the Images directory and displays quite happily in book view using the code above. However when I click on Delete Unused Media Files, I get cover.jpg listed as an unused file. Oddly, cover.jpeg which is unused is not flagged as unused.

When I click on Well-Formed Check EPUB, it complains about the code used to display the cover. Changing <image height="1500" width="1000" xlink:href="../Images/cover.jpg"></image> to <image height="1500" width="1000" xlink:href="../Images/cover.jpg" /> removes the error. I probably should use the second form but it's a bit of boilerplate I've used for quite a while and I've had no other epub check complain about it.

[KevinH]

I will check on how unused media are detected. It is a feature I have actually never used. If you can post a testcase (please no commercial ebooks) that demonstrates that issue it would certainly help. Perhaps your opf pointed to the other cover.jpeg and the xlink:href was ignored?

The svg image tag is a void tag (can have no contents) so the gumbo parser will enforce that. Although a closing image tag is allowed in pure xml it is not allowed in html5 and so creates problems with some tool chains, mainly those used in kindle conversion. Even the old Sigil 0.8.x series with Tidy fixed that particular issue to let kindlegen properly parse the resulting epub without errors.. Sigil cleans and serializes to polyglot xhtml/html5 so that your code will be correctly parsed by all ereaders whether based on html webkit engines, or pure xml engines.

KevinH

[DiapDealer]

I can't duplicate this. Even using DNSB's exact cover image code, I can't get Sigil to report that cover.jpg is unused using the Delete Unused Media Files tool. Nor can I get any unused images (included in the archive) to NOT be reported by the same tool.

I agree that a sample (non-copyrighted) epub would help immensely.

CORRECTION: if I have an epub with two manifested images (one named 'cover.jpg' and one named 'cover.jpeg').
1) use Tools->Add cover to create a cover image page using the 'cover.jpeg' image.
2) manually change the file name in the generated cover.xhtml (Code View) page to 'cover.jpg'
3) Run the Tools->Delete Unused Media File tool and the tool will report that 'cover.jpg' is unused. And the cover.jpeg file will be unreported (though that last is sort of understandable since 'cover.jpeg' is still listed in places in the opf file outside the manifest).

Unrelated cosmetic side note: the "Delete Unused Media Files" tool reports an "Unused media files deleted" status message whether the 'OK' button is clicked or the dialog is dismissed with the 'Cancel' button (status message only; images are not deleted when canceling).

[KevinH]

Hi DiapDealer,

I am not sure what is happening when you change the cover name in the xhtml file. The DeleteUnusedMedia routine invokes MainWindow::DeleteUnusedMedia() and the very first thing that it does is SaveTabData() which should force any changes made in BV/CV back to its Resource. So according to the code ... that should not be happening.

Very Strange!

KevinH

[KevinH]

Found the bug. It seems the gumbo_get_attribute call is not namespace aware. We asked it to find the xlink:href on image tags but it only looks at the local attribute name (href) and so did not detect it. The cover.jpeg itself is detected in the metadata in the opf, so it is never unused. The only way to change that is to use the AddSemantics dialog to change the cover image set.

I will update the gumbo code to allow namespaced searching for attributes to fix this. I will push these changes to master for the next release.

KevinH

ps: fix is now in master and will appear in Sigil-0.9.4
Thanks for your bug report!