Quote:
Originally Posted by st_albert
I also do a couple of other tweaks:
To prevent the "double cover" issue, I point the "cover" guide element to the actual cover image (not the cover.xhtml file) and delete the cover.xhtml file:
Code:
<reference type="cover" title="Cover" href="Images/cover.jpg"/>
|
In that case you should get the following epubcheck error message:
Code:
ERROR(OPF-032): Guide references 'OEBPS/Images/cover.jpg' which is not a valid 'OPS Content Document'.
because you can only link to
OPS Content Documents (=XML/(X)HTML files) in the guide section.
Quote:
Originally Posted by st_albert
and change the title of the "text" guide element to "Start Reading":
Code:
<reference type="text" title="Start Reading" href="Text/Chapter001.xhtml"/>
|
That information might actually be used by epub software for visually impaired readers, but, AFAIK, it's not strictly necessary. This tweak could be easily added to the KindleGen plugin.
Quote:
Originally Posted by st_albert
Beyond that, I don't do anything special to the mobi-precursor epub, other than avoiding CSS selectors such as :first-line and :first-letter that don't work reliably across all or most of the kindle variants.
|
I
might add a pseudo selector check, even though these selectors tend to work in azw3 books just fine and KindleGen complains only about some of them.
Quote:
Originally Posted by st_albert
Well, the only new feature I can think of off the top of my head would be the ability to configure it to save the mobi to the same path as the epub being edited, and use the same filename with mobi extension. E.g. if I'm editing ~/ebooks/MyNewBook/PigsInSpace.epub then the mobi would be ~/ebooks/MyNewBook/PigsInSpace.mobi. (That is, configure it to do so automatically, without having to edit the plugin's config file each time.)
|
AFAIK, it's not possible to get the file name of the epub book without doing some major Python black magic.
