Possible suggestion on getting Nook Color to recognize covers

[leday]

Posting this to the Calibre forums as something possibly to look into? Many of us with the new Nook Color are having a VERY hard time getting the NC to recognize and display the cover art for epubs sideloaded from Calibre. The following is my most recent post on this. I wonder if it is something that might be looked into so that this will work without us having to convert and reconvert the files before downloading them to the device?? Any comments/suggestions will be welcome.

Here is what I have found to get this to work every time:

I don't know if I am going to be explaining this so it makes sense, but I have found that the Nook Color doesn't seem to "like" the file structure of epub files generated by Caliber as much as it does those generated by Sigil.

For instance, when I reconverted epub-to-epub using Calibre alone (which puts all the epub text/files into one main folder as you can see when you explode the epub, and generates sometimes color.jpeg or color1.jpeg files, don't know why the difference), the NC still won't recognize the cover art on many occasions, even when adding the "cover=ID" line).

However, if I
1) first open the epub in Sigil (make any changes I want or not), and save the epub again, and

2) THEN go to Calibre and convert epub-to-epub (which puts the text/files into separate directory folders), and

3) make sure there is both a copy of cover.jpeg and cover.jpg in the same directory as the content.opf file AND in the Images directory folder that was generated, and

4) make sure both of these lines are in the manifest of the opf file (I know both is probably overkill, but, hey...it covers all the bases for me)

<item href="cover.jpeg" id="cover" media-type="image/jpeg"/>
<item href="cover.jpg" id="cover" media-type="image/jpeg"/>

Then, when the book is downloaded to the NC, it will recognize the cover art every single time, without even having to reboot my Nook.

The key is to open and then save the epub file in Sigil BEFORE reconverting it in Calibre and making sure the jpg/jpeg files are in their proper locations in the epub directories, adding the lines to the opf file and rebuilding the epub. Does that make any sense? Maybe Calibre ought to see about formatting their epub files using the same directory structure as Sigil does???

[Manichean]

From what I know, Calibre tries to get its ePub output as standard-conforming as possible. I don't know the "official" line on this, but personally, I'd like it to stay that way, especially if kludging together support for some special device entails getting the same file twice with different names. That only invites problems for other devices.

[theducks]

Originally Posted by Manichean

From what I know, Calibre tries to get its ePub output as standard-conforming as possible. I don't know the "official" line on this, but personally, I'd like it to stay that way, especially if kludging together support for some special device entails getting the same file twice with different names. That only invites problems for other devices.

[leday]

Yeah, but the output doesn't seem consistent to me. For instance, when I converted a bunch of files to epub using Calibre (some were epub-to-epub, and some pdf-to-epub), calibre would generate covers with different filenames, sometimes cover.jpeg and sometimes cover1.jpg, and also generate different file structures (at least it seemed to me). I couldn't figure out what was the common factor that made it do this, instead of the output and the file structures being the same type for all files.

However, when I first open and resave the epub files using Sigil, and THEN use Calibre to convert, then Calibre generates the SAME file structure for all files and does this absolutely consistently, and it is this one that seems to "work" for my device so that the cover art is displayed. (not sure if I am explaining that clearly at all....sorry).

[kovidgoyal]

calibre preserves the file structure of the input document, where possible. Sigil doesn't. I *highly* doubt the nook relies on epub file structure to detect covers. If ti did, t would be horribly broken.

[leday]

OK that makes sense. I just can't figure out why the Nook Color ISN'T recognizing the covers on my (DRM-stripped) epubs (and this is happening to a lot of other people if you look at the Nook threads on this) until I add the cover ID lines into the content.opf file and make sure the proper jpg images are there too. Very wierd, but as long as it works I can live with it....

[icon0clast]

Originally Posted by kovidgoyal

calibre preserves the file structure of the input document, where possible. Sigil doesn't. I *highly* doubt the nook relies on epub file structure to detect covers. If ti did, t would be horribly broken.

Clearly you haven't spent enough time with the nook color reader software.
Ok, "horribly broken" just might be a slight overstatement, but broken at the very least.

This is certainly a problem with the nc software, as it has trouble reading the covers of epubs that work just fine everywhere else. I've spent too much time pouring over exploded epubs comparing one where it did read the cover against one where it didn't and I can't spot the magic incantation that will make it see the covers consistently. If there's anything calibre can do to work around this until the nc gets bug-fixed, that would be fantastic. Otherwise I'm going to just use aldiko on my nc in the meantime.

[leday]

Originally Posted by icon0clast

Clearly you haven't spent enough time with the nook color reader software.
Ok, "horribly broken" just might be a slight overstatement, but broken at the very least.

This is certainly a problem with the nc software, as it has trouble reading the covers of epubs that work just fine everywhere else. I've spent too much time pouring over exploded epubs comparing one where it did read the cover against one where it didn't and I can't spot the magic incantation that will make it see the covers consistently. If there's anything calibre can do to work around this until the nc gets bug-fixed, that would be fantastic. Otherwise I'm going to just use aldiko on my nc in the meantime.

The steps that I outlined above that I did work every time for me (open/save the epub in Sigil, THEN reconvert epub-epub in Calibre and make sure the appropriate lines are added to the opf file and the appropriately names copies of the cover art are there). See my original post for full detail. I know it's a pain having to do all of that but this is a good workaround for me until Calibre can somehow work around this by itself, if possible that is...

[leday]

Using Calibre to explode the epub file structure AFTER I had saved the file using Sigil AND reconverted it epub-epub using Calibre yields the following:

A folder entitled META-INF
A folder entitled OEBPS (within this are 2 folders titled Images and Text)
. content.opf
. cover.jpeg
. cover.jpg
. mimetype
. stylesheet.css
. titlepage.xhtml
. toc.ncx

Calibre seems to generate this exact structure on all of the Sigil-saved epubs and this structure seems to be what I need to have this work. It has every time.

Note that I have 2 copies of the cover art (one jpeg and one jpg). Calibre generated the jpeg file but I had to place the jpg one in manually (I also placed both copies in the Images folder located within the OEBPS folder, just in case. It might be overkill, but...).

With this file structure, AND the copies of the images AND the TWO "cover-ID" lines added to the content.opf file, and then rebuilding the epub using Calibre, the covers show up every single time for me. Hope this makes sense.

(I tried to capture a screen shot, but I couldn't figure out how to do this...sorry)

[DiapDealer]

<item href="cover.jpeg" id="cover" media-type="image/jpeg"/>
<item href="cover.jpg" id="cover" media-type="image/jpeg"/>

Are you making sure there's a meta declaration in the opf that matches the id="cover" item in the manifest?

Example:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
blah
blah
<meta name="cover" content="cover-image" />
blah
blah
</metadata>
<manifest>
blah
blah
<item id="cover-image" href="images/cover.jpg" media-type="image/jpeg" />
blah
blah
</manifest>

Note that the bolded items should match.

[leday]

Originally Posted by DiapDealer

Are you making sure there's a meta declaration in the opf that matches the id="cover" item in the manifest?

Example:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
blah
blah
<meta name="cover" content="cover-image" />
blah
blah
</metadata>
<manifest>
blah
blah
<item id="cover-image" href="images/cover.jpg" media-type="image/jpeg" />
blah
blah
</manifest>

Note that the bolded items should match.

Not sure. The "cover.jpeg" line is already in the manifest, having been generated by the conversion. The ONLY thing I do to the opf file is add the "cover.jpg" line to the manifest. I don't make any other changes to the opf file. This has worked for me but I am not certain "why".

[leday]

Here is a section of a sample manifest section. The line is bold is the ONLY change I ever make.

<dc:language>en</dc:language>
<dc:creator opf:file-as="......snipped author name...." opf:role="aut">......snipped book name.....</dc:creator>
<meta name="calibre:timestamp" content="2009-12-22T09:00:00+00:00"/>
<dc:title>Megan's Mark</dc:title>
<meta name="cover" content="cover"/>
<dc:date>2006-05-01T08:00:00+00:00</dc:date>
<meta name="calibre:series" content="Breeds"/>
<dc:contributor opf:role="bkp">calibre (0.7.29) [http://calibre-ebook.com]</dc:contributor>
<dc:identifier opf:scheme="ISBN">9780425209646</dc:identifier>
<dc:identifier id="uuid_id" opf:scheme="uuid">8cda86a9-83d1-42be-b1f9-ed5b5818f439</dc:identifier>
<dc:subject>Romance - Breeds</dc:subject>
</metadata>

<manifest>
<item href="OEBPS/Images/index-1_1.png" id="index-1_1.png" media-type="image/png"/>
<item href="OEBPS/Text/index_split_000.html" id="index_split_000.html" media-type="application/xhtml+xml"/>
<item href="OEBPS/Text/index_split_009.html" id="index_split_009.html" media-
.....
blah
blah
blah
blah
.....
type="application/xhtml+xml"/>
<item href="OEBPS/Text/index_split_031.html" id="index_split_031.html" media-type="application/xhtml+xml"/>
<item href="cover.jpeg" id="cover" media-type="image/jpeg"/>
<item href="cover.jpg" id="cover" media-type="image/jpeg"/>
<item href="stylesheet.css" id="css" media-type="text/css"/>
<item href="titlepage.xhtml" id="titlepage" media-type="application/xhtml+xml"/>
<item href="toc.ncx" media-type="application/x-dtbncx+xml" id="ncx"/>
</manifest>

[icon0clast]

Isn't the element "id" supposed to be unique within an xml document? Having two items with id="cover" is probably technically invalid. (Not that any two xml parsers will ever agree on anything.) I realised that when I ran across this in one of my test books...

<item id="cover" href="cover.xhtml" media-type="application/xhtml+xml"/>

I tried to tweak that to use a different id (and add the id="cover" element pointing to the jpeg) and only succeeded in creating something that the nook would recognise the cover of, but couldn't open the book itself.

Could this all be as simple as perhaps the nook doesn't realize that 'jpeg' has in 'e' in it?

[leday]

Originally Posted by icon0clast

Isn't the element "id" supposed to be unique within an xml document? Having two items with id="cover" is probably technically invalid. (Not that any two xml parsers will ever agree on anything.) I realised that when I ran across this in one of my test books...

<item id="cover" href="cover.xhtml" media-type="application/xhtml+xml"/>

I tried to tweak that to use a different id (and add the id="cover" element pointing to the jpeg) and only succeeded in creating something that the nook would recognise the cover of, but couldn't open the book itself.

Could this all be as simple as perhaps the nook doesn't realize that 'jpeg' has in 'e' in it?

Possibly. I am not really code literate enough to understand all the intricasies on how this stuff really works. All I really know is that this fix does work for me, just not really how or why. Maybe it is only really a function of the fact that I make sure the epub contains a copy of "cover.jpg" and the "jpg" line is added to the manifest. The other steps might be unnecessary, but I haven't tested that at this point, since as what I am doing works for me, I'm getting the "if it ain't broke, don't fix it" feeling).

[leday]

Also. In retrospect.. putting. that line into the manifest BEFORE using Sigil still did not work either. Only after using Sigil did things work. I have no idea why. It is all very strange to me.