Modify ePub plugin dev thread - Page 20

jackie_w · 05-28-2012, 04:41 PM

Hi kiwidude,

I'm getting errors when trying to use the jacket options:

Remove all metadata jackets

Spoiler:

Add/replace metadata jacket

Spoiler:

I can send an epub link if you need it but I've had it happen on several different epubs.

[Edit:] oops!, I see you've just released a new version - I'll retry with that one.

jackie_w · 05-28-2012, 04:57 PM

ignore

kiwidude · 05-28-2012, 04:58 PM

@jackie_w - arghhhhhhhhhhhh.... you found another one. Try with the (new) new version above

jackie_w · 05-28-2012, 05:04 PM

Quote:

Originally Posted by kiwidude

@jackie_w - arghhhhhhhhhhhh.... you found another one.

One does what one can

The new one fixes the above jacket problems on my test file

jackie_w · 05-28-2012, 05:41 PM

@kiwidude,

FYI,

I tried the 'Insert or replace cover' as a single checked item. It seems OK so far.
I also tried 'Update metadata (including cover)' as a single checked item. The cover.jpeg file was correctly replaced with the new cover, however, in the file titlepage.xhtml the image dimensions in the svg viewbox and <image> tag retained the old cover dimensions.

kiwidude · 05-28-2012, 05:53 PM

@jackie_w - thx for the testing/feedback. There is nothing new about that behaviour, and that is exactly the same as what calibre does when you save to disk (it doesn't rewrite the titlepage image dimensions)?

jackie_w · 05-28-2012, 05:58 PM

Quote:

Originally Posted by kiwidude

@jackie_w - thx for the testing/feedback. There is nothing new about that behaviour, and that is exactly the same as what calibre does when you save to disk (it doesn't rewrite the titlepage image dimensions)?

OK, fair enough.

JSWolf · 05-28-2012, 07:21 PM

I'm still testing the cover feature.

JSWolf · 05-28-2012, 07:39 PM

I just found a bug in the replacing the cover. Links to the old cover XML have not been updated to point to the new cover. Also, the new cover XML is not put with the other XML files and the cover image is not put with the other images.

As for iBooks, the new cover does work fine. But the ToC does not work fine as it has a broken link to the old cover XML that no longer exists.

kiwidude · 05-29-2012, 02:53 AM

@JSWolf - I follow the same approach as the calibre conversion logic does of putting the replacement cover image and html page in the root of the epub, rather than trying to "guess" what the image and content directories are named. It is a possible enhancement to try to put them in similar places that I could attempt, though it is a pretty low priority given most users don't care about how the epub is structured internally (since the likes of Sigil will reorganise the content anyway).

As for the NCX - I need you to PM me a link to the epub in its "before" state so that I can see for myself what is happening. Certainly there is code in there intended to re-point the ncx to the new cover, but obviously you found a situation which beats that logic which is most definitely of interest to me.

kiwidude · 05-29-2012, 07:22 AM

@JSWolf - Ok, for the next version (not uploaded yet) I have changed it to attempt to put the generated cover image and titlepage into the appropriate subfolders if they exist in the epub. If the epub has no images it is going to put it in the root folder like it does currently - I don't want to artifically create a hierarchy by adding an images subfolder in case the epub had been intentionally "flattened" in the first place (since that is one of calibre's conversion options and was presumably created to support some device or something).

I have also added logic to ensure that if there is an *inline* TOC html page in the ePub with an entry pointing to the old cover html page, that it will be updated if that old cover page gets removed and the replacement has a different link required. I hadn't done this previously because (a) it means re-writing the html page and (b) I was being lazy, but it is the "right" thing to do.

With regards to the NCX - without seeing your example ePub I started experimenting to try to guess what had gone wrong. The one thing I have found was that if the .ncx is in a different folder to the .opf manifest then things do go a bit wrong. Even calibre gets that particular use case wrong as well during a conversion (Kovid may spot this, otherwise I'll raise a bug report tonight). Perhaps that was the issue with your ePub - regardless if you can send me a link to it to replicate it would be much appreciated.

JSWolf · 05-29-2012, 03:01 PM

Quote:

Originally Posted by kiwidude

@JSWolf - I follow the same approach as the calibre conversion logic does of putting the replacement cover image and html page in the root of the epub, rather than trying to "guess" what the image and content directories are named. It is a possible enhancement to try to put them in similar places that I could attempt, though it is a pretty low priority given most users don't care about how the epub is structured internally (since the likes of Sigil will reorganise the content anyway).

As for the NCX - I need you to PM me a link to the epub in its "before" state so that I can see for myself what is happening. Certainly there is code in there intended to re-point the ncx to the new cover, but obviously you found a situation which beats that logic which is most definitely of interest to me.

The NCX did get fixed. It was the internal ToC that wasn't fixed. Thanks for this fix.

That sounds good about the placing of the cover files. That should solve things fine. Ill give it some more testing once the next beta is ready. As for the cover, when you are replacing a cover, the plugin should know where the cover image was and where the conver XML was as well.

kiwidude · 05-29-2012, 04:21 PM

Right, here's another build (are we there yet?). Particular thanks to JSWolf for the latest feedback. This has these additions:

the cover image and titlepage file will be attempted to be placed in the same directory structure as any detected existing images/html pages
any inline TOC entries pointing to the old cover will be updated to point to the new cover.
should handle encoded images/cover page names (like when they have spaces in them)
handle the opf and ncx files being in different directories internally (not sure if this ever happens, but plugin should now cope with it)

Note the inline TOC behaviour above is different to what a calibre conversion does. During a conversion calibre scans the ebook looking for links to the existing cover from other html pages, and if found it decides to *keep* the existing cover page/image and leave links as they are. It then adds a second cover which is what you see at the front. I don't know the reasoning, it might be legacy logic, or there might be a valid reason.

I've decided for this plugin on the other hand that the presence of other html links to a cover page will not alter the decision on whether that page can be safely removed or not. (Only whether there are other images/text on that identified cover page will decide that).

The upshot being we should get cleaner, smaller epubs with a lower chance of double covers. Well until someone points out a flaw in the logic of course...

JSWolf · 05-29-2012, 04:33 PM

I found one thing that can be fixed with the new beta. The version number should be changed to reflect the current beta.

kiwidude · 05-29-2012, 04:44 PM

I'm going to release it as 1.2.0 when the final build is done, which will make sure that anyone who has been trying the beta will get notified via plugin updater. I could have called these beta versions 1.1.9, 1.1.10 etc before then but I hadn't expected there to be quite so many iterations required...

05-28-2012, 05:41 PM	#290
jackie_w Grand Sorcerer Posts: 6,212 Karma: 16534894 Join Date: Sep 2009 Location: UK Device: Kobo: KA1, ClaraHD, Forma, Libra2, Clara2E. PocketBook: TouchHD3	@kiwidude, FYI, I tried the 'Insert or replace cover' as a single checked item. It seems OK so far. I also tried 'Update metadata (including cover)' as a single checked item. The cover.jpeg file was correctly replaced with the new cover, however, in the file titlepage.xhtml the image dimensions in the svg viewbox and <image> tag retained the old cover dimensions.

05-28-2012, 07:39 PM	#294
JSWolf Resident Curmudgeon Posts: 73,970 Karma: 128903378 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	I just found a bug in the replacing the cover. Links to the old cover XML have not been updated to point to the new cover. Also, the new cover XML is not put with the other XML files and the cover image is not put with the other images. As for iBooks, the new cover does work fine. But the ToC does not work fine as it has a broken link to the old cover XML that no longer exists. Last edited by JSWolf; 05-28-2012 at 08:38 PM.

05-29-2012, 04:21 PM	#298
kiwidude Calibre Plugins Developer Posts: 4,637 Karma: 2162064 Join Date: Oct 2010 Location: Australia Device: Kindle Oasis	New beta version Right, here's another build (are we there yet?). Particular thanks to JSWolf for the latest feedback. This has these additions: the cover image and titlepage file will be attempted to be placed in the same directory structure as any detected existing images/html pages any inline TOC entries pointing to the old cover will be updated to point to the new cover. should handle encoded images/cover page names (like when they have spaces in them) handle the opf and ncx files being in different directories internally (not sure if this ever happens, but plugin should now cope with it) Note the inline TOC behaviour above is different to what a calibre conversion does. During a conversion calibre scans the ebook looking for links to the existing cover from other html pages, and if found it decides to keep the existing cover page/image and leave links as they are. It then adds a second cover which is what you see at the front. I don't know the reasoning, it might be legacy logic, or there might be a valid reason. I've decided for this plugin on the other hand that the presence of other html links to a cover page will not alter the decision on whether that page can be safely removed or not. (Only whether there are other images/text on that identified cover page will decide that). The upshot being we should get cleaner, smaller epubs with a lower chance of double covers. Well until someone points out a flaw in the logic of course... Last edited by kiwidude; 05-31-2012 at 04:52 PM. Reason: Removing attachment as later version in this thread

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Any web-to-epub plugin for internet browser?	bthoven	ePub	7	07-10-2011 05:14 AM
[Old Thread] Reading epub on viewer inexplicably changes the time stamp of epub	greenapple	Library Management	20	03-19-2011 10:18 PM
Easy way to modify thread subscription emails in bulk?	snipenekkid	Feedback	11	02-06-2011 03:47 AM
Another plugin dev question	DiapDealer	Plugins	2	12-11-2010 01:46 PM
Epub plugin dev	DiapDealer	Plugins	15	11-12-2010 09:36 AM

05-28-2012, 04:57 PM	#287
jackie_w Grand Sorcerer Posts: 6,212 Karma: 16534894 Join Date: Sep 2009 Location: UK Device: Kobo: KA1, ClaraHD, Forma, Libra2, Clara2E. PocketBook: TouchHD3	ignore

05-28-2012, 04:58 PM	#288
kiwidude Calibre Plugins Developer Posts: 4,637 Karma: 2162064 Join Date: Oct 2010 Location: Australia Device: Kindle Oasis	@jackie_w - arghhhhhhhhhhhh.... you found another one. Try with the (new) new version above

05-28-2012, 05:53 PM	#291
kiwidude Calibre Plugins Developer Posts: 4,637 Karma: 2162064 Join Date: Oct 2010 Location: Australia Device: Kindle Oasis	@jackie_w - thx for the testing/feedback. There is nothing new about that behaviour, and that is exactly the same as what calibre does when you save to disk (it doesn't rewrite the titlepage image dimensions)?

05-28-2012, 07:21 PM	#293
JSWolf Resident Curmudgeon Posts: 73,970 Karma: 128903378 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	I'm still testing the cover feature.

05-29-2012, 02:53 AM	#295
kiwidude Calibre Plugins Developer Posts: 4,637 Karma: 2162064 Join Date: Oct 2010 Location: Australia Device: Kindle Oasis	@JSWolf - I follow the same approach as the calibre conversion logic does of putting the replacement cover image and html page in the root of the epub, rather than trying to "guess" what the image and content directories are named. It is a possible enhancement to try to put them in similar places that I could attempt, though it is a pretty low priority given most users don't care about how the epub is structured internally (since the likes of Sigil will reorganise the content anyway). As for the NCX - I need you to PM me a link to the epub in its "before" state so that I can see for myself what is happening. Certainly there is code in there intended to re-point the ncx to the new cover, but obviously you found a situation which beats that logic which is most definitely of interest to me.

05-29-2012, 07:22 AM	#296
kiwidude Calibre Plugins Developer Posts: 4,637 Karma: 2162064 Join Date: Oct 2010 Location: Australia Device: Kindle Oasis	@JSWolf - Ok, for the next version (not uploaded yet) I have changed it to attempt to put the generated cover image and titlepage into the appropriate subfolders if they exist in the epub. If the epub has no images it is going to put it in the root folder like it does currently - I don't want to artifically create a hierarchy by adding an images subfolder in case the epub had been intentionally "flattened" in the first place (since that is one of calibre's conversion options and was presumably created to support some device or something). I have also added logic to ensure that if there is an inline TOC html page in the ePub with an entry pointing to the old cover html page, that it will be updated if that old cover page gets removed and the replacement has a different link required. I hadn't done this previously because (a) it means re-writing the html page and (b) I was being lazy, but it is the "right" thing to do. With regards to the NCX - without seeing your example ePub I started experimenting to try to guess what had gone wrong. The one thing I have found was that if the .ncx is in a different folder to the .opf manifest then things do go a bit wrong. Even calibre gets that particular use case wrong as well during a conversion (Kovid may spot this, otherwise I'll raise a bug report tonight). Perhaps that was the issue with your ePub - regardless if you can send me a link to it to replicate it would be much appreciated.

05-29-2012, 04:33 PM	#299
JSWolf Resident Curmudgeon Posts: 73,970 Karma: 128903378 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	I found one thing that can be fixed with the new beta. The version number should be changed to reflect the current beta.

05-29-2012, 04:44 PM	#300
kiwidude Calibre Plugins Developer Posts: 4,637 Karma: 2162064 Join Date: Oct 2010 Location: Australia Device: Kindle Oasis	I'm going to release it as 1.2.0 when the final build is done, which will make sure that anyone who has been trying the beta will get notified via plugin updater. I could have called these beta versions 1.1.9, 1.1.10 etc before then but I hadn't expected there to be quite so many iterations required...

Advert

Advert