Modify ePub plugin dev thread

[paulfiera]

Originally Posted by kovidgoyal

...But, that's not to say that I will refuse a patch for it.

That would be great. You could even set it as an option.

And now that I have you here...

Could you do something about this?

Basically, some epubs have the cover page in, say..."OEBPS/cover.html". When converting, this page is usually removed and the cover is placed in "Text/titlepage.xhtml", but this change is not reflected in toc.ncx, where it still points to the old non-existent file. I usually open the converted epubs in Sigil and update the TOC but I was wondering if this could be somehow automated in the conversion process.
Ah, and set its playOrder to 0 or 1. Some epubs place the cover as the last playOrder number, resulting - at least in iBooks - in the cover not opening when you first open the epub. I really don't know why some epub publishers think the cover is the last thing you need to see when you open an epub. I believe it should be the first.

[kovidgoyal]

@kiwidude: In that scenario, a single stylesheet will work. However, I am not going to accept an option for this. The correct solution, as I described before, is to put the rules into external stylesheets and link to them from the individual html files. A patch that does that, I will accept.

@paulfiera: Open a bug report for your issue, or it will get lost, I dont have the time to look into it right now.

[paulfiera]

Originally Posted by kovidgoyal

@paulfiera: Open a bug report for your issue, or it will get lost, I dont have the time to look into it right now.

Many thanks, Kovid. Will do.

[kiwidude]

Hi Kovid - ok, I guess I still don't see how that stylesheet thing might work, please bear with me as I get up to speed on this.

Take for instance the epub that is on this thread here at MobileRead by JSWolf:
https://www.mobileread.com/forums/sho...d.php?t=177182

It has embedded fonts, a single stylesheet, and @font-face declarations in that single stylesheet. It clearly was converted by calibre to epub at one point, and then the embedded fonts and declarations were done afterwards, quite possibly with Sigil by the looks of the metadata. So we are starting with a "perfect" epub - it has font-face declarations in a stylesheet, that is referenced from every html page.

So if I do an epub->epub conversion on that with calibre currently, the @font-face declarations now get moved into every single html file except the titlepage.xhtml (along with copying the page margins, which I know cause similar angst to some people).

In our "ideal" world, that wouldn't happen. Since you don't want an option to turn that off, you suggest instead a stylesheet referenced from every page. But there is already exactly just that? So what is the difference? Does it have to be *another* stylesheet? With special naming or something?

[kovidgoyal]

Yes it needs to be another stylesheet(s). You will want to collect all the different sets of font-face/page margin rules. Create new styleseets for every distinct set and then link to the appropriate stylesheet in every html file. Look at stylizer.py and flatcss.py, where all the stylesheet processing is done.

In your case that will mean one extra stylesheet in the resulting epub. For more complex books it will result in upto n+1 stylesheets where n is the number of html files.

[paulfiera]

Never mind

[kiwidude]

Moderator Notice
I moved all these recent posts back to this dev thread for the plugin since we are diverging into a few different subtopics.

@Kovid - thx again for that info. I'm not promising I have the capability to implement it of course but I will take a look at these files. I know next to nothing about calibre's conversion code/pipeline so rather a curve in there... what could possibly go wrong...

I took a read over this thread and I see much of these issues came up a year ago (fonts, margins etc) so perhaps it is time to try to do something about it.

[kovidgoyal]

If you get stuck, feel free to ask, preferably by email.

[kiwidude]

Originally Posted by dwanthny

Epubfixer appears to say that they do exactly what calibre does with covers by default whenever a book is converted. SVG is calibre's default method of formatting covers during a conversion.

Sorry Walt, I somehow missed this response, thanks for your checking.

My only concern with SVG is pure ignorance over exactly what it is and why you would want it . Kovid subsequently gave some info on this in that it allows full screen covers, and from reading around it seems that some devices don't support svg so hence there is an option to generate a simple image in a div tag instead.

I want to avoid having the Modify ePub dialog having loads of "suboptions" related to specific features. Perhaps I can follow Idolse's approach (I think) he took for page margins of getting the conversion default settings to decide whether to write out an svg cover or not.

[jackie_w]

@kiwidude,

I'm a regular user of ePubFixer. Just in case it helps I've attached a before-and-after version of the cover xhtml file. The 'before' is from a retail epub which has not been calibre converted.

The 'after' example is following use of the ePubFixer 'Edit Cover' option with 'Preserve Aspect Ratio' unchecked. If it had been checked the only difference would have been

preserveAspectRatio="xMidYMid meet"

rather than

preserveAspectRatio="none"

Before

Spoiler:

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta content="text/html; charset=UTF-8"/>
<link href="adle_9781101543535_oeb_css_r1.css" rel="stylesheet" type="text/css"/>
<title>.</title>
<link href="page-template.xpgt" rel="stylesheet" type="application/adobe-page-template+xml"/>
<meta content="urn:uuid:xxxxxxxxxxxxx" name="Adept.expected.resource"/>
</head>
<body style="margin-top:0px;margin-left:0px;margin-right:0px;margin-bottom:0px;text-align:center;background-color:#FFFFFF;">
<p><a id="cover"/></p>
<div class="centerAligned"><img alt="001" class="imgepub" src="adle_9781101543535_msr_cvi_r1.jpg" style="height:100%;text-align:center;"/></div>
</body>
</html>

After

Spoiler:

<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
  "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta content="text/html; charset=UTF-8" />
    <title>
      .
    </title>
    <meta content="urn:uuid:xxxxxxxxxxxxx" name="Adept.expected.resource" />
    <style type="text/css">
/*<![CDATA[*/
    body.c1 {margin:0; padding: 0; border-width: 0}
    /*]]>*/
    </style>
  </head>
  <body class="c1">
    <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" height="100%" preserveAspectRatio="none" version="1.1" viewBox="0 0 1071 1600" width="100%">
      <image height="1600" width="1071" xlink:href="adle_9781101543535_msr_cvi_r1.jpg"></image>
    </svg>
  </body>
</html>

(I've deliberately obliterated the 'urn:uuid:' code in case it revealed personal stuff???)

[kiwidude]

Thanks very much for that Jackie. And yeah that decision on preserve ratio or not is another of the settings that I hope I can grab from calibre's default conversion options rather than have to replicate onto this plugin UI.

[JSWolf]

Originally Posted by kiwidude

Thanks very much for that Jackie. And yeah that decision on preserve ratio or not is another of the settings that I hope I can grab from calibre's default conversion options rather than have to replicate onto this plugin UI.

IMHO, I'd prefer to have the aspect ratio kept with no option not to keep it. Those 510x680 resolution covers bother me because they aren't aspect correct.

[paulfiera]

Originally Posted by kovidgoyal

@paulfiera: Open a bug report for your issue, or it will get lost, I dont have the time to look into it right now.

Kovid, I opened a bug report for this issue yesterday, but now it looks like it's no longer there

[kovidgoyal]

https://bugs.launchpad.net/bugs/993812

[paulfiera]

Thanks!