Conditional code for Previewer conversion

[AlanHK]

I create books in ePub using Sigil and then convert to mobi using the Kindle Previewer.

Some things work in ePub but not in Kindle (cover links for one, since the conversion deletes the cover page).

It's tedious and error prone to create a special epub for conversion every time, so I wonder if conditional code can detect if it's in a mobi or epub file and display the appropriate code.

[Notjohn]

Alan, I upload the identical epub to the KDP. (I buy a copy as soon as the book goes lives, just in case the double-cover problem arises, as it occasionally does.)

I've never experienced a failure, and believe me, I check. I always buy the book, and if I revise it, I ask for the new version to be "pushed" to my Kindle archives. Though I work in epub, I consider the "mobi" the more important format, since Amazon sells 85-90 percent of my books, up from 80 percent a few years ago.

[Doitsu]

Originally Posted by AlanHK

Some things work in ePub but not in Kindle (cover links for one, since the conversion deletes the cover page).

Depending on the features that don't work you could use media queries to hide elements in MOBI/AZW3 books.

For more information, see Appendix C of the Kindle Publishing Guidelines.

[AlanHK]

Originally Posted by Notjohn

Alan, I upload the identical epub to the KDP. (I buy a copy as soon as the book goes lives, just in case the double-cover problem arises, as it occasionally does.)

I've never experienced a failure, and believe me, I check.

The specific problem is that in the Contents page I have a link to the xhtml cover page, which is omitted in the mobi conversion leaving the link dead. So I deleted the link but would prefer to have code that showed it in epub but not mobi.

For these books the client is a Mac person and serves the epub from his own site for iBooks, and also wants Kindle for Amazon, though I suspect sells very few.

Originally Posted by Doitsu

Depending on the features that don't work you could use media queries.

Thanks. I'll see if I can work them out.

[Hitch]

Originally Posted by AlanHK

The specific problem is that in the Contents page I have a link to the xhtml cover page, which is omitted in the mobi conversion leaving the link dead. So I deleted the link but would prefer to have code that showed it in epub but not mobi.

Why? Given that there's a Go To for the cover? If you leave that link in, for ePUB on iBooks, it won't display there, either. It's a bit of kerfuffle for no return, isn't it?

For these books the client is a Mac person and serves the epub from his own site for iBooks, and also wants Kindle for Amazon, though I suspect sells very few.

Thanks. I'll see if I can work them out.

Sorry--I don't think I understand what you want media queries or conditionals for. Is this because you don't want to take your ePUB file, and tweak it, a bit, for conversion to MOBI? You want One ePUB to Rule Them All? Without tweakage?

As I mentioned, the cover-on-the-TOC thing is moot. Doesn't work in MOBI (in fact, if you leave it in, as you've coded it, you can encounter the dreaded double cover problem); and if your client is a Mac/iPad person, that particular TOC item won't show up on the TOC, either. So, why put it on the TOC? If you don't, you solve two issues at once.

Can you advise exactly what you're trying to avoid? What step?

Hitch

[AlanHK]

Originally Posted by Hitch

Why? Given that there's a Go To for the cover? If you leave that link in, for ePUB on iBooks, it won't display there, either. It's a bit of kerfuffle for no return, isn't it?

It does work in iBooks.
Try not to assume, or at least not to imply, that I'm an idiot.

Originally Posted by Hitch

Sorry--I don't think I understand what you want media queries or conditionals for. Is this because you don't want to take your ePUB file, and tweak it, a bit, for conversion to MOBI? You want One ePUB to Rule Them All? Without tweakage?

I wanted to have the tweaks in the one file so I don't have to a manually change them every time I convert to mobi.

Originally Posted by Hitch

As I mentioned, the cover-on-the-TOC thing is moot. Doesn't work in MOBI

Of course it doesn't. That's why I wanted to make the dead link disappear on mobi.

Originally Posted by Hitch

(in fact, if you leave it in, as you've coded it, you can encounter the dreaded double cover problem); and if your client is a Mac/iPad person, that particular TOC item won't show up on the TOC, either. So, why put it on the TOC? If you don't, you solve two issues at once.

That's what I did. The deadline has passed, so this is now an academic question.

Can you advise exactly what you're trying to avoid? What step?
Hitch

If I wasn't clear, I'm sorry. Please just forget about it.

[Notjohn]

I'd tell the client that since the 15th century books have done without a TOC listing for the cover, and now is no time to start.

[Tex2002ans]

If you look at section 17.3.2 of the Kindle Publishing Guidelines, they give some CSS + HTML examples of using display:none + Media Queries.

You would just add a class around your "Cover" text in the TOC, and tell it to not display in KF8/MOBI.

Side Note: I am also in the camp of not having a link to the Cover in the TOC... along with links to other Front Matter (Title Page, Frontispiece, Copyright Page, Dedication, Acknowledgments, [...]). It just makes no sense!

Semi-Related Note: There was another topic about six months ago discussing the "Cover in TOC" (Hitch also answered there):

https://www.mobileread.com/forums/sho...d.php?t=263591

Semi-Related Note: Here was a topic where we discussed the Front Matter + layout of ebooks:

https://www.mobileread.com/forums/sho...d.php?t=228927

Definitely try to crack an egg of wisdom on the client's head instead.

Originally Posted by Notjohn

I'd tell the client that since the 15th century books have done without a TOC listing for the cover, and now is no time to start.

Want to read the Back Cover? Close book and turn over!

[Hitch]

Originally Posted by AlanHK

It does work in iBooks.
Try not to assume, or at least not to imply, that I'm an idiot.

I wasn't. Some while back--like...5 years ago, you literally couldn't get it to work. At that time, IIRC, the cover automatically displayed to the left of the TOC, so, Apple thought, "No reason to put the bloody cover in there," and they'd yank it out. I haven't checked in ages--obviously, you do have it working. Great. Then, if that's what your client wants, I understand the why. I really wasn't jerking you around.

I wanted to have the tweaks in the one file so I don't have to a manually change them every time I convert to mobi.

Yup, I get it. I don't believe that there's a way to do what you want, not how you want it. Just using media queries probably wouldn't solve it. I haven't tried, but we use quite a few MQ, and in thinking about it (see my stream-of-consciousness discussion with Tex)...I don't see the "how."

Of course it doesn't. That's why I wanted to make the dead link disappear on mobi.

In terms of "tedious and error prone," all we do is remove cover.xhtml. That's it. Make sure that the meta is in place, remove the xhtml, and build. I know that's not what you asked, but in case you're doing something differently..?

That's what I did. The deadline has passed, so this is now an academic question.

@Tex2002ans:

You would just add a class around your "Cover" text in the TOC, and tell it to not display in KF8/MOBI.

Warning: thinking aloud. So, you'd write a media query, that leaves it for the ePUB, but hides it for the media-KF8 and KF7? That might work. The question is, what happens to the TOC link, which, presumably, goes to the xhtml file OR the id of the cover page, when that page is removed or destroyed in the Kindlegen process? And does it matter? I mean, does it matter if the link is bogus or broken, if it's going to be hidden anyway?

The other quesion is, can you put AMZN media queries in an ePUB and stil have it pass ePUBcheck? Our experiences with AMZ media queries has been that normally, they affect the ePUB vis-a-vis ePUBcheck.

If I wasn't clear, I'm sorry. Please just forget about it.

I was simply trying to understand the "how" of how you built your mobis, and what part of it you were trying to omit. I am constantly surprised at the myriad ways that folks build MOBI files--and that's why I asked.

Hitch

[AlanHK]

Originally Posted by Tex2002ans

If you look at section 17.3.2 of the Kindle Publishing Guidelines, they give some CSS + HTML examples of using display:none + Media Queries.

Thanks. Looks a useful technique I should get familiar with whether I use it in this instance or not.

Originally Posted by Tex2002ans

Side Note: I am also in the camp of not having a link to the Cover in the TOC... along with links to other Front Matter (Title Page, Frontispiece, Copyright Page, Dedication, Acknowledgments, [...]). It just makes no sense!

Certainly used by me and the publisher, to make it easy to check everything is there.

As for the reader, I'm not trying to force them to read all the copyright notices and such, but a few lines in the TOC won't hurt them and it reminds them that these pages exist, as they may skip directly to the main text on opening and never see a hint of their existence otherwise.
Of course that isn't necessary in a printed book, 15th century or 21st.

[Tex2002ans]

Originally Posted by Hitch

The question is, what happens to the TOC link, which, presumably, goes to the xhtml file OR the id of the cover page, when that page is removed or destroyed in the Kindlegen process?

Not too sure what would happen to the cover file though, since I know Amazon messes with that in a separate process. (As you mentioned, if you relied on display:none, you would probably still get the "double cover").

Side Note: I never really looked too deeply into it until today (so take this as all educated guesswork).

To my knowledge, if there is display: none, the content goes poof (and doesn't exist) in the resultant MOBI HTML.

I ran the example EPUB below using KindleGen, then checked the HTML from KindleUnpack. It looks as if the display: none code doesn't appear in the MOBI7 at all.

It does appear in the KF8 though, and is marked with a new attribute:

data-AmznRemoved="mobi7"

Side Note on the Side Note: I wonder if this also falls into our discussion on "Page Numbers"/"Locations" in ebooks. I bet the Amazon Location algorithm also has to take into account all of these data-AmznRemoved attributes so that the MOBI/KF8 locations match.

Originally Posted by Hitch

The other quesion is, can you put AMZN media queries in an ePUB and stil have it pass ePUBcheck? Our experiences with AMZ media queries has been that normally, they affect the ePUB vis-a-vis ePUBcheck.

I don't believe epubcheck complains about Kindle Media Queries.... although I must admit, I never went too crazy on them.

I attached a sample EPUB that has Kindle Media Queries + passes epubcheck 3.0 with zero complaints.

I just grabbed a simple Media Query Dropcap example from somewhere, and just added some code to it to make sure the media queries were working.

This code in the TOC:

<h2>Table of Contents</h2>

  <p class="nokf8"><a href="../Text/cover.xhtml">Cover (Everything non-KF8)</a></p>

  <p class="nomobi"><a href="../Text/TOC.xhtml">Table of Contents (Everything non-MOBI)</a></p>

  <p><a href="../Text/Chapter1.xhtml">Chapter 1 (Everything)</a></p>

and this in the CSS:

span.dropcaps {
    font-weight: normal;
	font-style : italic; 
    font-size: 2em; 
    float: left; 
}

p.nomobi, p.nokf8 {
	/* This should make sure it displays on everything else */
	display: block;
}

/* Kindle-specific CSS */ 
@media amzn-kf8 { 
  span.dropcaps { 
    font-weight: normal;
	font-style: normal; 
    font-size: 320%; 
    float: left; 
    margin-top: -0.3225em; 
    margin-bottom: -0.3245em;
  }
	p.nokf8 {
		display: none;
	}
} 
@media amzn-mobi { 
  span.dropcaps { 
    font-size: 3em; 
    font-weight: bold; 
  } 
	p.nomobi {
		display: none;
	}
}

Ran it through KingleGen and it seems to display as it should: