Sigil 0.3.4 / Sigil 0.4.0 RC1 / Cover in Nook Color

[Bertrand]

Hi

Here's my workflow, when doing an epub :
1 - ODT file
2 - Export in epub format with Writer2Epub
3 - Open in Sigil 0.3.4
4 - First page : Add image > Add semantics > Cover image
5 - Save
6 - Add in Calibre
7 - From there, send to device (Nook Color)

The cover displays fine on the device, in the library.

Now, same workflow, except at step 3 :
- Open in Sigil 0.4.0 RC1

No cover on device.

I checked the HTML code, the OPF file and others.
I don't see any difference between Sigil 0.3 and 0.4.


Any idea why ?

Thanks

[st_albert]

Version 0.4.0RC-1 is known to have issues that corrupt the content.opf file under certain circumstances (albeit not, on the face of it, your circumstances).

In any event, more detail would be helpful. Could you post both epubs -- the one that works and the one that doesn't for us to examine? It could be a small, made-up example, so long as it demonstrates the defect.

[Bertrand]

Thanks for the reply.

Here are my tests files.
Both files are identical.
Test_Sigil04.epub : the cover doesn't show up on my Nook Color

[st_albert]

Yes, they are almost identical, but I do see some differences in the content.opf file.

for one thing, Sigil ver 0.4 uses a different order for the parameters inside each metadata item. for example, version 0.3.4 has:

<         <meta name="cover" content="cover.jpg"/>
<         <meta name="Sigil version" content="0.3.4"/>
...
<         <item id="ncx" href="toc.ncx" media-type="application/x-dtbncx+xml"/>
<         <item id="cover.jpg" href="Images/cover.jpg" media-type="image/jpeg"/>
<         <item id="style001.css" href="Styles/style001.css" media-type="text/css"/>
<         <item id="content0001.xhtml" href="Text/content0001.xhtml" media-type="application/xhtml+xml"/>

...

and ver. 0.4 has:

>     <meta content="cover.jpg" name="cover" />
>     <meta content="0.4.0" name="Sigil version" />
...
>     <item href="toc.ncx" id="ncx" media-type="application/x-dtbncx+xml" />
>     <item href="Styles/style001.css" id="style001.css" media-type="text/css" />
>     <item href="Text/content0001.xhtml" id="content0001.xhtml" media-type="application/xhtml+xml" />

...

and so on. I don't know if the order matters to some reader software but not others.

If you're comfortable unpacking and repacking epubs, you might try substituting the 0.3.4 version of content.opf into the 0.4 epub, and see if it then displays the title. I don't have a nook, so I can't try it myself.

I did try them on ADE, firefox add-in, and Calibre's reader, and everything looked the same (i.e. title present) on all readers. So it might be a nook thing.

[Bertrand]

After some tests, I think I have found what the Nook Color does not like in content.opf.

This line, from Sigil 0.4 :
<meta content="cover.jpg" name="cover" />
= not good for the Nook, doesn't display the cover.

This line, from Sigil 0.3 :
<meta name="cover" content="cover.jpg" />
= Happy Nook : cover OK

I thought the attribute order was not important, but apparently it is, for the Nook software.

(All this because I want to use the TOC panel in Sigil 0.4 - so much easier to browse through the book)

Thanks for your answers, st_albert !

[theducks]

Originally Posted by Bertrand

After some tests, I think I have found what the Nook Color does not like in content.opf.

This line, from Sigil 0.4 :
<meta content="cover.jpg" name="cover" />
= not good for the Nook, doesn't display the cover.

This line, from Sigil 0.3 :
<meta name="cover" content="cover.jpg" />
= Happy Nook : cover OK

I thought the attribute order was not important, but apparently it is, for the Nook software.

(All this because I want to use the TOC panel in Sigil 0.4 - so much easier to browse through the book)

Thanks for your answers, st_albert !

You should report this Nook bug to the Nook (B&N) developers

[st_albert]

Can anyone tell me whether the epub spec's require the attributes to be listed in any particular order? I tried to wade into the OPF specs, but soon realized I was in over my head. Nevertheless I didn't see anything suggesting that the attributes had to be in any particular order.

That said, I prefer the order provided in Sigil 0.3.4 just on the basis of readability.

But if order DOES matter, this should also be reported to Sigil's issue tracker as well. Maybe it should be reported there anyway, just for completeness.

And thank you Bertrand for finding this out. Yet another quirk to be aware of when trying to prepare epubs that work for arbitrary reading systems.

[Jellby]

Originally Posted by st_albert

Can anyone tell me whether the epub spec's require the attributes to be listed in any particular order?

As far as I know, the OPF is based on XML syntax, where the order of attributes is immaterial (as long as there is no conflict, at least).

[user_none]

The spec says it needs to validate and it does. As jellby said order of attributes should not matter. That said it's worth looking into changing to accommodate the Nook (I have a touch and this change still conforms to the spec).

Please open a bug on Sigil's bug tracker. Include what was found as far as getting covers to show on the Nook and a link to this thread. This way I won't forget to look into changing the order back to how 0.3 has them. This way others can see the issue and look into it if I'm taking too long.

Even with possibly changing Sigil, B&N's reader is still wrong and they really need to fix it.

[Hitch]

Originally Posted by user_none

Please open a bug on Sigil's bug tracker. Include what was found as far as getting covers to show on the Nook and a link to this thread. This way I won't forget to look into changing the order back to how 0.3 has them. This way others can see the issue and look into it if I'm taking too long.

Even with possibly changing Sigil, B&N's reader is still wrong and they really need to fix it.

And while you're at it, could you kick their asses about this damned hyphenation thing? Wins my vote (next to Apple's "Double Secret Probation Submission Requirements that We Did NOT Put In The Guidelines and We Don't Explain" thing) as Dumbest. Thing. Ever.

Hitch

[Bertrand]

Originally Posted by user_none

Please open a bug on Sigil's bug tracker.

Done. Issue 942.

[Valloric]

Originally Posted by user_none

The spec says it needs to validate and it does. As jellby said order of attributes should not matter. That said it's worth looking into changing to accommodate the Nook (I have a touch and this change still conforms to the spec).

Please open a bug on Sigil's bug tracker. Include what was found as far as getting covers to show on the Nook and a link to this thread. This way I won't forget to look into changing the order back to how 0.3 has them. This way others can see the issue and look into it if I'm taking too long.

Even with possibly changing Sigil, B&N's reader is still wrong and they really need to fix it.

Xerces in Sigil is the one reordering attributes and there's no way to make it not do that (I looked). The Xerces devs say (rightly so) that attribute order is irrelevant in XML so they took some liberties with optimizing attribute storage internally (the use a dict, so they don't store the original order). When it's time to serialize the XML back from the DOMDocument into a string, attributes are written out in alphabetical order.

Again, they're right, the XML spec says that attribute order is arbitrary.

[user_none]

Originally Posted by Valloric

Xerces in Sigil is the one reordering attributes and there's no way to make it not do that (I looked).

That's what I was afraid of...

[Valloric]

Originally Posted by user_none

That's what I was afraid of...

Yeah, I don't like it either. I wanted to preserve the XML in the same normalization form it came in. But the spec is clear; attribute order is arbitrary and no distinctions should be made based on attribute order serialization.

I spent a few days hacking on xerces to change this behavior, but I eventually got nowhere. Fun fact: xerces devs use c++ exceptions for control flow (look at the entity parsing code). Who in their right mind...