When you convert an ePub that has embedded font code in the CSS to ePub, Calibre decides it's a good idea to take out the font code from the CSS and put it in all of the XML files. Why?

This is a rather silly thing to do (IMHO) and is a bug that should (IMHO) be fixed.

Because that allows you to have per html global style rules. All @ css rules are put into each html flow separately.

Because that allows you to have per html global style rules. All @ css rules are put into each html flow separately.

And if I decide to change the font being used, I have to edit every single XML file. Not a good idea at all.

In fact, I try to do away with the @css rules other then font stuff.

As long as I am here, why does Calibre also put in a top and bottom margin of 5pt (in every XML) when it converts to ePub when I'm specifying a top and bottom margin of 0?

Probably I am misunderstanding something as I am not a CSS person.

Mostly I use the tweak epub option and edit the stylesheet.css when a file defies my attempts to make it how I want it to be. (Weird margins, indents, coloured backgrounds, bold, italics etc.)

This seems to change all of the html files in the epub including the font and font sizes, styles?

Helen

Probably I am misunderstanding something as I am not a CSS person.

Mostly I use the tweak epub option and edit the stylesheet.css when a file defies my attempts to make it how I want it to be. (Weird margins, indents, coloured backgrounds, bold, italics etc.)

This seems to change all of the html files in the epub including the font and font sizes, styles?

Helen

This certainly controls the styling but does not remove embedded @page styles that calibre inserts in each XHTML file, and hence the 5pt margin that JSWolf mentions. The ePub can be tweaked to regex them out but it would be nice to have an option not to generate them in the first place. I don't know if kiwidude's Modify ePub plugin can remove them.