[GUI Plugin] Modify ePub

[enuddleyarbl]

I've started seeing this just recently, so I'm not sure if something's changed with new Calibre releases, I'm doing something different, and/or I've lost my mind. If I run Modify ePub (v 1.7.3) against an epub3 book in Calibre 6.4, the @page class in stylesheet.css gets messed up. First, Calibre adds that @page thing during conversion, but I modified it slightly to include a comment. Here's what it looks like now:

@page {
/* Basic Styling for what passes for pages in an epub */
  margin-top: 0;
  margin-left: 0;
  margin-right: 0;
  margin-bottom: 0;
}

If I run Modify ePub against a book with that in it, afterwards that @page class will look like this:

@page { margin-top: 0; margin-left: 0; margin-right: 0; margin-bottom: 0;/* Basic Styling for what passes for pages in an epub */
  margin-top: 0 }

The log for that run looks like:

Modify ePubs version (1, 7, 3)
Logfile for book ID 285 (My Test Book - 0 Margins / me)
Job details 285
  Modifying:  C:\Users\Dave\AppData\Local\Temp\calibre_g_x6det9\mwzd7iwe_modify_epub\285.epub
	Updating metadata and cover
	  Parsing xml file: content.opf
	  Parsing xml file: toc.ncx
	Looking for redundant entries in manifest
	Looking for unmanifested files
	Looking for broken links in the NCX
	ncx name:  toc.ncx
	Looping over ncx entries
	Looking for Adobe xpgt files and links to remove
	Looking for pagemaps
	Looking for Google Play pagemaps
	Looking for Adobe DRM meta tags to remove
	Looking for legacy jackets
	Adding or updating jacket
	 Current jacket removed:  jacket.xhtml
	  Manifest item removed: jacket.xhtml (calibre_jacket)
	  Spine itemref removed: calibre_jacket
	  Manifest item added: jacket.xhtml (calibre_jacket)
	  Spine item inserted: calibre_jacket at pos: 1
	Looking for html pages containing only broken image links
	Looking for non dc: elements in manifest
	  Removing child: {http://www.idpf.org/2007/opf}meta
	  Removing child: {http://www.idpf.org/2007/opf}meta
	  Removing child: {http://www.idpf.org/2007/opf}meta
	  Removing child: {http://www.idpf.org/2007/opf}meta
	  Removing child: {http://www.idpf.org/2007/opf}meta
	  Removing child: {http://www.idpf.org/2007/opf}meta
	  Removing child: {http://www.idpf.org/2007/opf}meta
	  Removing child: {http://www.idpf.org/2007/opf}meta
	Looking for html files to remove charset meta tags/encode to utf-8
	Looking for embedded fonts
	Looking for css @font-face style declarations
	Looking for inline @font-face style declarations
	Looking for CSS margins
	  Modified inline CSS margins in: margintest.xhtml
	  Modified CSS margins in: stylesheet.css
	Looking for inline javascript blocks to remove
	Looking for .js files to remove
	Applying smarten punctuation
	Stripping Kobo remnants
	Looking for files to remove: ['iTunesMetadata.plist', 'iTunesArtwork']
	Looking for files to remove: ['META-INF/calibre_bookmarks.txt']
	  Found file to remove: META-INF/calibre_bookmarks.txt
	Looking for files to remove: ['.DS_Store', 'thumbs.db']
	Looking for unused images
	Stripping spans
	Unprettying files
ePub updated in 0.07 seconds

To me, it looks like Modify ePub is recreating all the @page margin settings and then appending my comment and the first of my margin settings to that. I don't know why. If it were just cosmetics, that'd be no problem. But, Calibre's Check Book function doesn't like the duplicate margin-top at all.

Unfortunately, with chaley's comment a couple of pages back that he doesn't really maintain this any more, and with davidfor's recent passing (it looks like he did some work with the PI), I'm not sure if anyone can fix this. But, I'd appreciate it if someone would run the PI and check their @page class before and after.

[JSWolf]

Originally Posted by enuddleyarbl

I've started seeing this just recently, so I'm not sure if something's changed with new Calibre releases, I'm doing something different, and/or I've lost my mind. If I run Modify ePub (v 1.7.3) against an epub3 book in Calibre 6.4, the @page class in stylesheet.css gets messed up.

There is a very simple solution that does not require any changes to the plugin. Load the eBook into the editor. View the CSS and while viewing the CSS, press the icon that looks like an orange flower (that's Beautify current file). That will fix @page and any other CSS style that's not as you want.

[enuddleyarbl]

OK. It's the comment that's causing the problem (which is odd because the PI has no problem with any other comments in my stylesheet.css). If I pull the comment out of my @page, Modify ePub works correctly. So, that's easily worked around.

And, let me throw in the options I use when I run Modify ePub: everything's checked (turned on) except Remove Unmanifested Files From Epub, Remove ONLY Google Play Page Maps, Flatten TOC Hierarchy in NCX File, Append Extra CSS, Remove All Metadata Jackets, Jacket at the End of the Book, Remove Existing Cover, and Insert or Replace Cover (that last one I'll use on epub2 books -- but it messes up the cover on epub3 books).

[enuddleyarbl]

Originally Posted by JSWolf

There is a very simple solution that does not require any changes to the plugin. Load the eBook into the editor. View the CSS and while viewing the CSS, press the icon that looks like an orange flower (that's Beautify current file). That will fix @page and any other CSS style that's not as you want.

Thanks. But doing a Beautify just moves the malformed @page's lines around and fixes the indentation. The extra margin-top stays there.

[JSWolf]

Originally Posted by enuddleyarbl

OK. It's the comment that's causing the problem (which is odd because the PI has no problem with any other comments in my stylesheet.css). If I pull the comment out of my @page, Modify ePub works correctly. So, that's easily worked around.

And, let me throw in the options I use when I run Modify ePub: everything's checked (turned on) except Remove Unmanifested Files From Epub, Remove ONLY Google Play Page Maps, Flatten TOC Hierarchy in NCX File, Append Extra CSS, Remove All Metadata Jackets, Jacket at the End of the Book, Remove Existing Cover, and Insert or Replace Cover (that last one I'll use on epub2 books -- but it messes up the cover on epub3 books).

That comment is useless anyway. It does nothing for nobody.

[DNSB]

Perhaps moving the comment outside the definition?

/* Basic Styling for what passes for pages in an epub */
@page {
  margin-top: 0;
  margin-left: 0;
  margin-right: 0;
  margin-bottom: 0;
}

[enuddleyarbl]

Originally Posted by DNSB

Perhaps moving the comment outside the definition?

/* Basic Styling for what passes for pages in an epub */
@page {
  margin-top: 0;
  margin-left: 0;
  margin-right: 0;
  margin-bottom: 0;
}

I moved my comments inside the definition because when I run the Calibre Editor's "Remove Unused CSS Rules", it leaves the "outside the definition" comments behind when it removes an unused rule. With the comment in the definition, the comment goes away with the rule. EDIT: Since @page is never removed by Calibre, I guess that's not an issue here. So, moving the comment out would work.

In this case, since @page is exactly the same in every book that I've run through Calibre, and the rule isn't exactly complex, removing the comment entirely is a reasonable workaround.

[mrevent]

Very useful plug-in, thank you!
I would suggest adding a "unsmarten punctuation" option besides the "smarten" one, especially given the recent problems with curly quotes in kindle books sent as epub.

[JSWolf]

Originally Posted by mrevent

Very useful plug-in, thank you!
I would suggest adding a "unsmarten punctuation" option besides the "smarten" one, especially given the recent problems with curly quotes in kindle books sent as epub.

Smart quotes shouldn't be a problem if you use Modify ePub to make sure the ePub is in UTF-8.

[halorrr]

I've had a few ePubs fail to send to Kindle. Once I tried opening them in the Kindle Previewer software I found the issue was that a couple of the files contained these properties in the body tag:

data-AmznRemoved-M8="true" data-AmznRemoved="mobi7"

I found this thread http://www.mobileread.mobi/forums/sh...272407&page=55 that mentioned these being attributes left over from an original Kindle source.

Could we get an option in the plugin to remove these in order to make the process less manual?

[DNSB]

Originally Posted by halorrr

I've had a few ePubs fail to send to Kindle. Once I tried opening them in the Kindle Previewer software I found the issue was that a couple of the files contained these properties in the body tag:

data-AmznRemoved-M8="true" data-AmznRemoved="mobi7"

I found this thread http://www.mobileread.mobi/forums/sh...272407&page=55 that mentioned these being attributes left over from an original Kindle source.

Could we get an option in the plugin to remove these in order to make the process less manual?

Odd. I've sent several books to Amazon as epub that contains those media queries and no issues were caused. If properly used, they allow the same source file to generate valid KF8 and mobi output with images not looking grunged.

[halorrr]

Originally Posted by DNSB

Odd. I've sent several books to Amazon as epub that contains those media queries and no issues were caused. If properly used, they allow the same source file to generate valid KF8 and mobi output with images not looking grunged.

Weird for me it was blocking some books from converting. The Kindle Previewer would give this error:

E21018: Enhanced Mobi building failure, while parsing content in the file. 
Content: <data-AmznRemoved> in file: /private/var/folders/l4/y1bdd37n1955jm7mjqls0vt00000gn/T/cf3432b2-887f-432c-be43-99229faf6eff/cTemp/mTemp/mobi-d1h5qx/text/part0001.html line: 4294967295
Book conversion failed.

Removing the attribute fixed it for me. I guess this is were it being an option of the plugin to remove would be handy. I guess if they are done right, then there is no reason to turn the option on, but if a book is failing to send because of the attributes, it would be nice to be able to quickly remove them.

[chrisridd]

Originally Posted by halorrr

Weird for me it was blocking some books from converting. The Kindle Previewer would give this error:

E21018: Enhanced Mobi building failure, while parsing content in the file. 
Content: <data-AmznRemoved> in file: /private/var/folders/l4/y1bdd37n1955jm7mjqls0vt00000gn/T/cf3432b2-887f-432c-be43-99229faf6eff/cTemp/mTemp/mobi-d1h5qx/text/part0001.html line: 4294967295
Book conversion failed.

It may be unrelated, but really line 4294967295? That's the largest value of an unsigned 32 bit integer.

[halorrr]

Originally Posted by chrisridd

It may be unrelated, but really line 4294967295? That's the largest value of an unsigned 32 bit integer.

That is weird, I didn't notice that. I'm happy to DM someone one of the files I experienced this with if they want to poke at it.

[jberanek]

So, I just discovered this plugin, after finding a lot of Epub files I obtained looking corrupted on Kindle, due to the UTF-8 encoding issue.

Using the plugin's "Encode HTML in UTF-8" option does correct the encoding (the originals have <meta charset="utf-8"> and not an XML encoding specifier) but the book's title is getting corrupted into something like "osctyCaS5qIgdGTUOQHIG3" and the cover photo is lost.

Using the latest version of the plugin, along with calibre 6.5 and sending books to the Kindle via kindle.com email.

Is this a known issue, do any of the vast array of options in the plugin possibly fix this?