'mark as cover image'

[u238110]

Why do I have the option to mark both an xhtml file as a 'cover image' and an image as a cover image? Why wouldn't there just be one 'cover image' option? This seems so silly and unintuitive.

[eschwartz]

This question seems silly and unintuitive.

Well, so are the EPUB "standards".

Both are needed and for obvious reasons should match.

Kindle formats will just use the marked image, EPUB looks for the coverpage (but I think not all readers).

[u238110]

The fact that the two actions aren't tied together is what seems silly. Redundant is a better word and honestly I'm sure any software engineer would agree with me. And I didn't understand your explanation.

[theducks]

Because a coverpage COULD be text with a smaller image (eg the old Calibre look)

So the page needs to be ID'd

then the image flagged, just in case an automater wants to replace just that piece

[Ghitulescu]

I understand the OP confusion.

A book can only have a cover. At least paperbooks have (the others are named differently).
So if one marks an image as a cover, why the (X)HTM(L) file can be set as well? And if it's required to be this a cover why the image retains its status?

Speaking of this: I have yet to find the "uncover" option, id est to remove the cover-status of a file....

Anyway, no hardware eReaders I have was able to display an image as a cover, only XHTML files (which may include an image).

[JSWolf]

The problem is that there are two ways for an ePub reader to decide what to use as the cover image. One is to take the first page of the ePub and use that as the cover. The other is to look for a meta tag for the cover in the OPF and then use the graphic pointed to by the meta tag for the cover. This only effects thumbnails as in cover view.

[DiapDealer]

There are perfectly valid reasons to want to have an image marked as the cover image (in the OPF metadata) WITHOUT having an html cover page (even one that contains the same image) marked as a cover page (in the OPF guide section) as a consequence.

Taking away someone's ability to do the one without the other (by automatically linking the two actions) would be presumptuous.

Quite simply put: cover page and cover image are not synonymous with each other. So 'marking' them should remain independent of each other.

[Ghitulescu]

Originally Posted by DiapDealer

There are perfectly valid reasons to ....

Such as?

[theducks]

Originally Posted by Ghitulescu

Such as?

As my Dad would say...
"Them's the RULES.

Follow them."

[DiapDealer]

Originally Posted by Ghitulescu

Such as?

Such as wanting to have an image marked as a cover image (metadata section of the opf) with no (x)html cover page (guide section of the opf), or vice-versa--wasn't I clear??

That fact that the EPUB spec ALLOWS such things--coupled with the fact the people have expressed an interest in wanting to DO such things--should be reason enough for anyone that the actions remain independent of each other.

Add to that the fact that they're just not the same things. I don't know how much simpler I can put it. One can exist without the other in a validating epub. Knowing that, I should think the ability to be able to mark them independently would appeal to common sense.

[Ghitulescu]

Originally Posted by DiapDealer

Such as wanting to have an image marked as a cover image (metadata section of the opf) with no (x)html cover page (guide section of the opf), or vice-versa--wasn't I clear??

That fact that the EPUB spec ALLOWS such things--coupled with the fact the people have expressed an interest in wanting to DO such things--should be reason enough for anyone that the actions remain independent of each other.

Add to that the fact that they're just not the same things. I don't know how much simpler I can put it. One can exist without the other in a validating epub. Knowing that, I should think the ability to be able to mark them independently would appeal to common sense.

I don't care whether the EPUB specs allows it or not. This is not an argument to do things, just because they are permitted. This is all that I could understand from your statements, sorry.
I understand also that you think you're clear, because you know more than you said - why would one have an image marked as cover yet another file x/htm/l marked as well?

For instance, my Sony does not recognize images as covers, even if marked as such, a text file however yes. Neither the Trekstor. So marking an image as cover does not solve the problem of displaying it as cover in all cases. Therefore the ability to mark a text document as a cover is not only handy but also required.

[DiapDealer]

Originally Posted by Ghitulescu

Therefore the ability to mark a text document as a cover is not only handy but also required.

But it's NOT "required" it's permitted. The EPUB2 spec has no standard for dealing with cover images, so I would think flexibility would be desirable in an editor to help accommodate varying device/app implementations (plus there's the fact that calibre's editor is not JUST an epub editor).

You've also managed to argue your way right into supporting the idea that the actions of "marking" a cover page|image should remain independent of each other. In your examples, you don't NEED the image to be marked as a cover image ... you only need to indicate the cover page in order for it to display properly on the devices you indicated. So why would you want calibre's editor to automatically mark the image as well when you don't need it to?

Never mind the fact that calibre's editor also allows the editing of AZW3 kindle files -- which use images as covers and NOT html pages.

There's seriously more reasons for keeping the actions separate than there are reasons for pointlessly (and quite possibly detrimentally) linking them. You not seeing them doesn't make them any less valid.

[arspr]

This discussion is pretty pointless...

OK, in most books, the cover html file (which is explicitly set as this kind of file in guide section) just contains a link (in either img or svg>image flavour) to a bitmap which is also set as cover image (in metadata section).

But you can freely do whatever other combinations you want. So, therefore, they cannot be directly linked. Period. Now, discuss whatever you want but it's absurd IMO.

Maybe your cover.html just contains text, or maybe it contains only SVG vector shapes, or maybe it contains three bitmaps. Or maybe you just want to set one of them (or none of them).

If you are really interested, what you could propose would be an enhancement to Calibre where, whenever you set an html file as cover type, IF AND ONLY IF it only contained a single link to an image, Calibre automatically suggested you to mark that image as cover... As you can imagine I cannot foretell Kovid's answer, but I'll bet to "sure, patches are welcomed" .

[theducks]

1 line of code in the OPF
vs
how many lines in this thread

[BetterRed]

Originally Posted by theducks

1 line of code in the OPF
vs
how many lines in this thread

I remove covers from epub files - although I keep a cover in the calibre library. If didn't use the calibre library I would consider keeping the image in the epub but not show it as a front cover - I'd probably put it at the back with the metadata jacket.

BR