Modify ePub plugin dev thread - Page 22

jackie_w · 05-31-2012, 12:48 PM

@kiwidude,

Just some positive feedback... I have used the 'replace cover' several times today. It's worked perfectly every time, including making sure any inline TOC link to cover works. I normally completely ignore inline TOCs as a waste of pages, but I made the effort to check.

As for what the filename of the cover is... I don't understand why anyone would care. In fact I quite like the fact that 'calibre moulded' epubs have a cover called cover.jpeg. It saves time having to work it out. Perhaps, I'm in the minority

kiwidude · 05-31-2012, 12:58 PM

@jackie_w - excellent, glad to hear it is working well for you. After all the false starts with my silly errors in earlier betas I think it is finally at the stage it should be.

As for the file naming, yeah my compromise was "I'll think about it"

. You ask why anyone would care - I tried that argument once before on this thread and he who shall not be named stated otherwise

. I really want to get this officially released and given my recent track record of breaking things I certainly don't intend to change it for the 1.2.0 release.

I am however very interested if JSWolf (or anyone else) has found an inline TOC that didn't update correctly, since my only experiences have matched what you have said of it all working fine. Certainly if the book had a broken inline TOC before conversion this plugin isn't going to magically fix it. But until I see it in its original state for myself I don't know for sure whether there is a bug in there or not.

JSWolf · 05-31-2012, 02:19 PM

Quote:

Originally Posted by jackie_w

@kiwidude,

Just some positive feedback... I have used the 'replace cover' several times today. It's worked perfectly every time, including making sure any inline TOC link to cover works. I normally completely ignore inline TOCs as a waste of pages, but I made the effort to check.

As for what the filename of the cover is... I don't understand why anyone would care. In fact I quite like the fact that 'calibre moulded' epubs have a cover called cover.jpeg. It saves time having to work it out. Perhaps, I'm in the minority

I'm not suggesting keeping the name of the cover image but the name of the cover XML. That is a big difference.

JSWolf · 05-31-2012, 02:20 PM

I'll give it another test and then if it is still broken, I'll PM.

jackie_w · 05-31-2012, 02:33 PM

Quote:

Originally Posted by JSWolf

I'm not suggesting keeping the name of the cover image but the name of the cover XML. That is a big difference.

Honestly, I can't say I care about that either. If its always called titlepage.xhtml, at least I know what it is. Once again, I'm not claiming to speak for the majority

JimmXinu · 05-31-2012, 02:35 PM

Well, if there's a vote going on, I'd say cover.xhtml is even less ambiguous.

JSWolf · 05-31-2012, 02:37 PM

I just managed to get the plugin to not only not replace the cover link in the internal ToC, but I've gotten it to also not replace the cover link in the ncx.

kiwidude · 05-31-2012, 02:41 PM

@JSWolf - my guess (and it is only that without the PM which I am sure you are typing right now) is that your epub does not identify at all what the existing cover is. i.e. no guide information and no meta tag. In that situation this plugin will not know that it is a cover and so won't go looking for TOC items internal or external to update.

JSWolf · 05-31-2012, 02:45 PM

Quote:

Originally Posted by kiwidude

@JSWolf - my guess (and it is only that without the PM which I am sure you are typing right now) is that your epub does not identify at all what the existing cover is. i.e. no guide information and no meta tag. In that situation this plugin will not know that it is a cover and so won't go looking for TOC items internal or external to update.

In the resulting ePub with the changed cover, the file originally used by the cover has been deleted. So I would have to think that the plugin knew which was the cover XML.

PM sent. I'm going to test again with just changing the cover and none of the other options. But as this is a fresh DRM strip, I figured removing the other junk at the same time would save one run of the plugin.

kiwidude · 05-31-2012, 02:52 PM

Ahhh... I believe the problem is that you had "Remove existing cover" ticked as well as "Insert or replace cover". With just "Insert or replace cover" ticked it works fine.

Those two options really are mutually exclusive. Perhaps I need to throw a warning up stopping that from happening or something.

JSWolf · 05-31-2012, 02:52 PM

I've found the bug. When both Remove existing cover and Insert or replace cover are checked, yes, I get the new cover, but the links in the two ToC do not get changed.

JSWolf · 05-31-2012, 02:53 PM

Quote:

Originally Posted by kiwidude

Ahhh... I am guess the problem is that you had "Remove existing cover" ticked as well as "Insert or replace cover". With just "Insert or replace cover" ticked it works fine.

Those two options really are mutually exclusive. Perhaps I need to throw a warning up stopping that from happening or something.

Or make it if one is checked, it unchecks the other.

Without remove existing cover checked and all the other options checked, yes, it does update the two cover links.

theducks · 05-31-2012, 03:00 PM

Quote:

Originally Posted by jackie_w

@kiwidude,

Just some positive feedback... I have used the 'replace cover' several times today. It's worked perfectly every time, including making sure any inline TOC link to cover works. I normally completely ignore inline TOCs as a waste of pages, but I made the effort to check.

As for what the filename of the cover is... I don't understand why anyone would care. In fact I quite like the fact that 'calibre moulded' epubs have a cover called cover.jpeg. It saves time having to work it out. Perhaps, I'm in the minority

The only case I could come up with is for some really wierd reason, there was a reference to the cover somewhere else in the book. As I said... WEIRD

kiwidude · 05-31-2012, 03:01 PM

Yeah, there are two things here. The first is the bug in the Remove cover functionality, which is not removing the NCX entry, and also not doing the inline TOC.

The second is whether I should allow a user to select both options in the first place and interrupt the user. Or if behind the scenes I should just detect that the user had both selected and ignore the "Remove existing cover" option in that circumstance, which is probaby my preference.

The issue is that if I allow them to run in sequence (once the bugs are fixed), is that you will by doing so have lost both a link in your internal TOC and in your external TOC to the cover. Now since it was clearly your intent to put a cover into the epub, I see no use case where you intentionally want any existing pointers to the cover being lost?

JSWolf · 05-31-2012, 03:06 PM

Quote:

Originally Posted by kiwidude

Yeah, there are two things here. The first is the bug in the Remove cover functionality, which is not removing the NCX entry, and also not doing the inline TOC.

The second is whether I should allow a user to select both options in the first place and interrupt the user. Or if behind the scenes I should just detect that the user had both selected and ignore the "Remove existing cover" option in that circumstance, which is probaby my preference.

The issue is that if I allow them to run in sequence (once the bugs are fixed), is that you will by doing so have lost both a link in your internal TOC and in your external TOC to the cover. Now since it was clearly your intent to put a cover into the epub, I see no use case where you intentionally want any existing pointers to the cover being lost?

If you don't want to go down the road of only allowing one of the two options checked, then I'd vote for the just ignoring the removing cover option.

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-31-2012, 12:48 PM	#316
jackie_w Grand Sorcerer Posts: 6,252 Karma: 16544692 Join Date: Sep 2009 Location: UK Device: ClaraHD, Forma, Libra2, Clara2E, LibraCol, PBTouchHD3	@kiwidude, Just some positive feedback... I have used the 'replace cover' several times today. It's worked perfectly every time, including making sure any inline TOC link to cover works. I normally completely ignore inline TOCs as a waste of pages, but I made the effort to check. As for what the filename of the cover is... I don't understand why anyone would care. In fact I quite like the fact that 'calibre moulded' epubs have a cover called cover.jpeg. It saves time having to work it out. Perhaps, I'm in the minority

05-31-2012, 12:58 PM	#317
kiwidude Calibre Plugins Developer Posts: 4,730 Karma: 2197770 Join Date: Oct 2010 Location: Australia Device: Kindle Oasis	@jackie_w - excellent, glad to hear it is working well for you. After all the false starts with my silly errors in earlier betas I think it is finally at the stage it should be. As for the file naming, yeah my compromise was "I'll think about it" . You ask why anyone would care - I tried that argument once before on this thread and he who shall not be named stated otherwise . I really want to get this officially released and given my recent track record of breaking things I certainly don't intend to change it for the 1.2.0 release. I am however very interested if JSWolf (or anyone else) has found an inline TOC that didn't update correctly, since my only experiences have matched what you have said of it all working fine. Certainly if the book had a broken inline TOC before conversion this plugin isn't going to magically fix it. But until I see it in its original state for myself I don't know for sure whether there is a bug in there or not.

05-31-2012, 02:20 PM	#319
JSWolf Resident Curmudgeon Posts: 79,796 Karma: 146391129 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	I'll give it another test and then if it is still broken, I'll PM.

05-31-2012, 02:35 PM	#321
JimmXinu Plugin Developer Posts: 6,980 Karma: 4604635 Join Date: Dec 2011 Location: Midwest USA Device: Kobo Clara Colour running KOReader	Well, if there's a vote going on, I'd say cover.xhtml is even less ambiguous.

05-31-2012, 02:37 PM	#322
JSWolf Resident Curmudgeon Posts: 79,796 Karma: 146391129 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	I just managed to get the plugin to not only not replace the cover link in the internal ToC, but I've gotten it to also not replace the cover link in the ncx.

05-31-2012, 02:41 PM	#323
kiwidude Calibre Plugins Developer Posts: 4,730 Karma: 2197770 Join Date: Oct 2010 Location: Australia Device: Kindle Oasis	@JSWolf - my guess (and it is only that without the PM which I am sure you are typing right now) is that your epub does not identify at all what the existing cover is. i.e. no guide information and no meta tag. In that situation this plugin will not know that it is a cover and so won't go looking for TOC items internal or external to update.

05-31-2012, 02:52 PM	#325
kiwidude Calibre Plugins Developer Posts: 4,730 Karma: 2197770 Join Date: Oct 2010 Location: Australia Device: Kindle Oasis	Ahhh... I believe the problem is that you had "Remove existing cover" ticked as well as "Insert or replace cover". With just "Insert or replace cover" ticked it works fine. Those two options really are mutually exclusive. Perhaps I need to throw a warning up stopping that from happening or something.

05-31-2012, 02:52 PM	#326
JSWolf Resident Curmudgeon Posts: 79,796 Karma: 146391129 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	I've found the bug. When both Remove existing cover and Insert or replace cover are checked, yes, I get the new cover, but the links in the two ToC do not get changed.

05-31-2012, 03:01 PM	#329
kiwidude Calibre Plugins Developer Posts: 4,730 Karma: 2197770 Join Date: Oct 2010 Location: Australia Device: Kindle Oasis	Yeah, there are two things here. The first is the bug in the Remove cover functionality, which is not removing the NCX entry, and also not doing the inline TOC. The second is whether I should allow a user to select both options in the first place and interrupt the user. Or if behind the scenes I should just detect that the user had both selected and ignore the "Remove existing cover" option in that circumstance, which is probaby my preference. The issue is that if I allow them to run in sequence (once the bugs are fixed), is that you will by doing so have lost both a link in your internal TOC and in your external TOC to the cover. Now since it was clearly your intent to put a cover into the epub, I see no use case where you intentionally want any existing pointers to the cover being lost?

Advert

Advert