Thread: [GUI Plugin] Modify ePub
View Single Post
Old 04-24-2015, 07:40 AM   #918
Rev. Bob
Wizard
Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.
 
Rev. Bob's Avatar
 
Posts: 1,760
Karma: 9918418
Join Date: Feb 2013
Location: Here on the perimeter, there are no stars
Device: Kobo H2O, iPad mini 3, Kindle Touch
Quote:
Originally Posted by cybmole View Post
so having this trailing at end of each chapter is redundant and can also generate spurious blank pages, depending on how the reader apps deal with an empty div.

i'd class it as redundant, like you do un-needed spans, and strip it because it is clutter that has no effect on how the epub is rendered.
Oh, I quite understand the reasoning, and even agree with the principle. The trouble is that it's dangerous to make assumptions without thorough investigation.

For instance, I've got several Kindle books that pack multiple chapters into one HTML file. I wouldn't want to remove those internal page-breaks, because then the chapters wouldn't get separated, and that starts interfering with the intended presentation.

("But you can split chapters by having calibre look for headers!"
"Not if the author uses paragraphs with big fonts instead of header tags."
"Why would anyone do that?"
"Got me... but it happens. Go figure.")

Then there's the question of how reliable the class name is. Maybe it's a native EPUB where the author manually placed a page-break element at the bottom of each document, only he called his class "pbr" because it's nice and short. Same effect, different code.

The plugin's simply not built to handle "if the document starts or ends in an empty element whose only function is to generate a page break, remove that element." It's not smart enough for that; that takes human intervention, just as "remove any blank-space paragraphs at the end of a document" does. (Yeah, that happens, too. I've even seen one publisher whose chapters gain an extra containing DIV as the book progresses. Chapter One might have two, Chapter Two three, up until Chapter Ninety-Seven having 98 of the damned things. Ebook code is easy to screw up.)

However, if I can verify that the class name is stable, I could possibly remove such elements at the top or bottom of the BODY element. Maybe. It depends, on those and other factors, and my natural inclination is to not use automation to interfere unless I can be confident in the results. I hate changing that stuff by hand, too, but I hate it much less than trying to figure out where things used to be.

So: While I may be able to do something, I'm not committing to it without having the chance to investigate. Could happen, could not, too soon to tell. Shake the 8-ball, ask again later.
Rev. Bob is offline   Reply With Quote