[GUI Plugin] Modify ePub - Page 45

BetterRed · 05-13-2014, 04:14 AM

Quote:

Originally Posted by eschwartz

I don't think calibre updates fields to empty, since that could mean wiping data accidentally -- although some people control their db metadata well enough that it would be intentional.

If I clear Comments in a book and do a Polish then the resultant EPUB in the library has no Comments in it. If I delete a cover from a book and do a Polish the resultant EPUB has no cover on it.

But if I clear Publisher & Tags and do a Polish then the Publisher & Tags remain the same.

Hmmmm

BR

brserek · 05-15-2014, 05:16 AM

So it's a Calibre thing? Then I'll report a bug.

brserek · 05-15-2014, 01:59 PM

I had reported a bug earlier today and already received a answer - it will be corrected in next release.

BetterRed · 05-15-2014, 04:46 PM

@brserek

for you and

for Kovid

BR

brserek · 05-16-2014, 02:32 AM

I can confirm, bug was corrected today. Kovid is really amazing.

cybmole · 05-22-2014, 11:51 AM

add/delete cover code - I have been helped but the Kobo adroid app feedback guys re an issue with this feature gnereated an unwanted blank page when the book is sideloaded & opened in the Kobo app:

i.e. any book that goes thru add/delete cover & is then imported to kobo IOS or android app shows as having 2 title page pages - one with the cover image , and one blank page.

the "fix" is to change height from 100% to 98% in the SVG tag.

I've asked if KObo will add a post here backing me up as it's their work that has uncovered this fix.

could it, without detriment to other devices, be adopted within a future plug in version please

Code:

<svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 299 500" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
<image height="500" width="299" xlink:href="../Images/cover.jpeg"></image>
</svg>

would become this ( image dimensions will vary form book to book)

Code:

<svg xmlns="http://www.w3.org/2000/svg" height="98%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 299 500" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
<image height="500" width="299" xlink:href="../Images/cover.jpeg"></image>
</svg>

Rev. Bob · 05-22-2014, 01:25 PM

The blank page is probably coming from a surrounding <p> element's normal margin, not the SVG code itself; you're shrinking the cover enough that the skipped line after it fits on the same page. That's why I use this cover-page code instead; it has no such problems, because there's no top/bottom margin at all:

Code:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
<head>
<title>Cover</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<style type="text/css">
@page { margin: 0; padding: 0; }
body, div { margin: 0; padding: 0; }
body { background-color: #000000; color: #ffffff; }
div { text-align: center; page-break-after: always; }
img { height: 100%; max-width: 100%; }
</style>
</head>
<body><div>
<img alt="Cover" title="Cover" src="cover image"/>
</div></body>
</html>

cybmole · 05-22-2014, 01:32 PM

i appreciate that there are other valid coding solutions, but I'm wanting to suggest that the plug-in code is changed so that it just works, for books on tablets, without the need for manual redoing of each book.

I have not as yet looked at how sigil / calibre editor process an insert image action, so see if they do it in the same way as this plug in does.

anyway, it has nothing to do with a surrounding <p> tag as there isn't one. look at the entirety of a titlepage as generated by the insert or replace cover action:

Code:

<head>
<meta content="true" name="calibre:cover" />
 
<title>Cover</title>
<style type="text/css">
@page {padding: 0pt; margin:0pt}
body { text-align: center; padding:0pt; margin: 0pt; }
</style>
</head>
 
<body>
<div>
<svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 299 500" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
<image height="500" width="299" xlink:href="../Images/cover.jpeg"></image>
</svg>
</div>
</body>
</html>

the only difference between your code & the plug-in code seems to be the use of <svg> & I have no idea why that tag was chosen for this function , rather than a simple <img> tag?.

I am pretty sure that insert or replace cover writes all the above code, and discards whatever was there before

theducks · 05-22-2014, 01:57 PM

Quote:

Originally Posted by cybmole

i appreciate that there are other valid coding solutions, but I'm wanting to suggest that the plug-in code is changed so that it just works, for books on tablets, without the need for manual redoing of each book.

I have not as yet looked at how sigil / calibre editor process an insert image action, so see if they do it in the same way as this plug in does.

anyway, it has nothing to do with a surrounding <p> tag as there isn't one. look at the entirety of a titlepage as generated by the insert or replace cover action:

Code:

<head>
<meta content="true" name="calibre:cover" />
 
<title>Cover</title>
<style type="text/css">
@page {padding: 0pt; margin:0pt}
body { text-align: center; padding:0pt; margin: 0pt; }
</style>
</head>
 
<body>
<div>
<svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 299 500" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
<image height="500" width="299" xlink:href="../Images/cover.jpeg"></image>
</svg>
</div>
</body>
</html>

the only difference between your code & the plug-in code seems to be the use of <svg> & I have no idea why that tag was chosen for this function , rather than a simple <img> tag?.

I am pretty sure that insert or replace cover writes all the above code, and discards whatever was there before

The S in SVG is scalable. IMHO a better way to go and the code shown also preservesthe Aspect

No

stretched cover images

cybmole · 05-22-2014, 02:28 PM

Quote:

Originally Posted by theducks

The S in SVG is scalable. IMHO a better way to go and the code shown also preservesthe Aspect

No

stretched cover images

yes, the existing code is very sensible,but unfortunately it causes the kobo tablet apps to glitch & to show an extra blank page.

here's what kobo android feedback/ support said to me:
I just ran my epub on iOS, saw the same issue, so it's not just an Android issue.
I think I know what is happening though, and it is indeed due to the css being added for the cover page by the modify epub plugin. It looks as though the image size specified in the css is bigger than what would be displayed on a single page, so it's causing a blank page to be inserted.
I also believe I've found a solution, or at least it works for me on iOS, so could be worth you giving it a try. ...

then the change 100% to 98% suggestion

PeterT · 05-22-2014, 02:49 PM

I seriously doubt that a representative from Kobo will make ANY post here suggesting a fix to the issue.

jackie_w · 05-22-2014, 04:35 PM

It's not a general Android issue. The Mantano, UBReader, Pocketbook reading apps (to name but 3) work fine with SVG covers coded in the 'standard calibre' way, so it seems to be Kobo-specific.

If I'm not mistaken, for many of its options Modify Epub just calls existing main calibre methods to do its work, so I wouldn't think it likely main calibre would be changed to accommodate the Android Kobo app. My eink Kobos also appear to cope well with 100% SVG settings, at least in standard epubs, don't know about kepubs.

cybmole · 05-23-2014, 01:48 AM

>peter T: kobo don't need to show now,a s posted their suggestiogn anyway. FOr all was know they are alaready lkunking/postign under screen names- maybe you are one of them

>Jackie- yes I guessed Kobo would be the odd one out & thus insufficient case for changing calibre code. It's no great hardship to have to flick past one blank page & I was more interested in why it happened than in how to prevent it in future. Maybe they will tweak their apps one day. At least I've learnt how to contact their App support and that they do respond.

cybmole · 05-23-2014, 01:54 AM

Quote:

Originally Posted by theducks

The S in SVG is scalable. IMHO a better way to go and the code shown also preserves the Aspect

No

stretched cover images

yep, Google is my friend, again. but the VG is for Vector Graphics & cover images are .jpg files - no vectors in there ?

so is the svg still superior to the img tag?

Rev. Bob · 05-23-2014, 02:03 AM

Quote:

Originally Posted by theducks

The S in SVG is scalable. IMHO a better way to go and the code shown also preservesthe Aspect

No

stretched cover images

If you mean my code, the combination of height and max-width preserves the aspect ratio, unless the cover dimensions are way off - for instance, wider than it is tall.

Not that I have anything against SVG, but normally I just don't see the need for it and believe that avoiding it lowers the odds of implementation problems. As always, YMMV.

05-22-2014, 11:51 AM	#666
cybmole Wizard Posts: 3,720 Karma: 1759970 Join Date: Sep 2010 Device: none	add/delete cover code - I have been helped but the Kobo adroid app feedback guys re an issue with this feature gnereated an unwanted blank page when the book is sideloaded & opened in the Kobo app: i.e. any book that goes thru add/delete cover & is then imported to kobo IOS or android app shows as having 2 title page pages - one with the cover image , and one blank page. the "fix" is to change height from 100% to 98% in the SVG tag. I've asked if KObo will add a post here backing me up as it's their work that has uncovered this fix. could it, without detriment to other devices, be adopted within a future plug in version please Code: <svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 299 500" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink"> <image height="500" width="299" xlink:href="../Images/cover.jpeg"></image> </svg> would become this ( image dimensions will vary form book to book) Code: <svg xmlns="http://www.w3.org/2000/svg" height="98%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 299 500" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink"> <image height="500" width="299" xlink:href="../Images/cover.jpeg"></image> </svg>

05-22-2014, 01:32 PM	#668
cybmole Wizard Posts: 3,720 Karma: 1759970 Join Date: Sep 2010 Device: none	i appreciate that there are other valid coding solutions, but I'm wanting to suggest that the plug-in code is changed so that it just works, for books on tablets, without the need for manual redoing of each book. I have not as yet looked at how sigil / calibre editor process an insert image action, so see if they do it in the same way as this plug in does. anyway, it has nothing to do with a surrounding <p> tag as there isn't one. look at the entirety of a titlepage as generated by the insert or replace cover action: Code: <head> <meta content="true" name="calibre:cover" /> <title>Cover</title> <style type="text/css"> @page {padding: 0pt; margin:0pt} body { text-align: center; padding:0pt; margin: 0pt; } </style> </head> <body> <div> <svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 299 500" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink"> <image height="500" width="299" xlink:href="../Images/cover.jpeg"></image> </svg> </div> </body> </html> the only difference between your code & the plug-in code seems to be the use of <svg> & I have no idea why that tag was chosen for this function , rather than a simple <img> tag?. I am pretty sure that insert or replace cover writes all the above code, and discards whatever was there before Last edited by cybmole; 05-22-2014 at 01:35 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[GUI Plugin] Quality Check	kiwidude	Plugins	1277	10-21-2025 10:04 AM
[GUI Plugin] Open With	kiwidude	Plugins	404	02-21-2025 05:42 AM
[GUI Plugin] Manage Series	kiwidude	Plugins	167	07-28-2024 03:07 PM
Modify ePub plugin dev thread	kiwidude	Development	346	09-02-2013 05:14 PM
[GUI Plugin] Plugin Updater Deprecated	kiwidude	Plugins	159	06-19-2011 12:27 PM

05-15-2014, 05:16 AM	#662
brserek Junior Member Posts: 7 Karma: 10 Join Date: Aug 2011 Device: oyo	So it's a Calibre thing? Then I'll report a bug.

05-15-2014, 01:59 PM	#663
brserek Junior Member Posts: 7 Karma: 10 Join Date: Aug 2011 Device: oyo	I had reported a bug earlier today and already received a answer - it will be corrected in next release.

05-15-2014, 04:46 PM	#664
BetterRed null operator (he/him) Posts: 22,012 Karma: 30277294 Join Date: Mar 2012 Location: Sydney Australia Device: none	@brserek for you and for Kovid BR

05-16-2014, 02:32 AM	#665
brserek Junior Member Posts: 7 Karma: 10 Join Date: Aug 2011 Device: oyo	I can confirm, bug was corrected today. Kovid is really amazing.

05-22-2014, 02:49 PM	#671
PeterT Grand Sorcerer Posts: 13,693 Karma: 79983758 Join Date: Nov 2007 Location: Toronto Device: Libra H2O, Libra Colour	I seriously doubt that a representative from Kobo will make ANY post here suggesting a fix to the issue.

05-22-2014, 04:35 PM	#672
jackie_w Grand Sorcerer Posts: 6,269 Karma: 16544702 Join Date: Sep 2009 Location: UK Device: ClaraHD, Forma, Libra2, Clara2E, LibraCol, PBTouchHD3	It's not a general Android issue. The Mantano, UBReader, Pocketbook reading apps (to name but 3) work fine with SVG covers coded in the 'standard calibre' way, so it seems to be Kobo-specific. If I'm not mistaken, for many of its options Modify Epub just calls existing main calibre methods to do its work, so I wouldn't think it likely main calibre would be changed to accommodate the Android Kobo app. My eink Kobos also appear to cope well with 100% SVG settings, at least in standard epubs, don't know about kepubs.

05-23-2014, 01:48 AM	#673
cybmole Wizard Posts: 3,720 Karma: 1759970 Join Date: Sep 2010 Device: none	>peter T: kobo don't need to show now,a s posted their suggestiogn anyway. FOr all was know they are alaready lkunking/postign under screen names- maybe you are one of them >Jackie- yes I guessed Kobo would be the odd one out & thus insufficient case for changing calibre code. It's no great hardship to have to flick past one blank page & I was more interested in why it happened than in how to prevent it in future. Maybe they will tweak their apps one day. At least I've learnt how to contact their App support and that they do respond.

Advert

Advert