View Single Post
Old 07-03-2012, 09:12 AM   #199
kiwidude
Calibre Plugins Developer
kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.
 
Posts: 4,640
Karma: 2162064
Join Date: Oct 2010
Location: Australia
Device: Kindle Oasis
Quote:
Originally Posted by JSWolf View Post
Kiwidude, can we have an option to delete @page please?
First things first - no I am not going to add an explicit option on the UI for removing @page - for all the reasons stated perfectly by Idolse.

I do agree that writing a blank @page {} section for when you have your defaults set to zero is a minor bug. I also found a bug in the existing version of the code which would cause the plugin to error - if you set your default margins to zero, and run it against an ePub which has margins specified (i.e. an epub that has been converted by calibre).

However in looking through and fixing/experimenting with all of this, I have a bigger question, which perhaps Kovid can answer.

When I set margins to zero and do a calibre conversion, calibre will write out an @page directive with margin-top: 0 and margin-bottom: 0. Now if JSWolf had his way, he doesn't want that to exist. This plugin behaves differently to calibre - if a margin is set to zero, it does not write any style attribute out for it - i.e. rather than writing "margin-top: 0" it will omit the margin-top atribute from that style. With my fixes/enhancements then if the style declaration has no other attributes then the style itself gets deleted, and if the css file has no other styles then the css file gets deleted and any links removed to it from other files. Which negates the need for any special "Remove @page" type of option completely.

However my big question is whether that the right thing to be doing? It is my understanding of the html standard that it is possible for a *browser* to enforce margins on a document. Does such a thing exist in the ePub reader world? The advantage of what Kovid's conversion logic does is that it ensures that the browser margins if they exist will get override to be zero. If you instead omit the margin-top: 0, then according to the standard the document will inherit the "browser's" top margin.

My concern is that if we continue the "zero margins means make sure no attribute in the style for it" approach then it actually becomes counter-productive and the users end up with a bigger margin that they can't control?

I don't care about cosmetic reasons on whether an @page directive does or does not exist in the css file. However I am *very* interested in the implications of a zero margin versus an unspecified margin in an @page directive. Thoughts?
kiwidude is offline   Reply With Quote