html conversion bug in 0.6xx series?

[slantybard]

Okay, I have noticed on some of my zipped html books that ePub conversion in 0.6xx produces ePubs with the body text "squished" into about an inch of the middle of the screen on my 505. Previously, the conversions using the 0.5xx series of calibre handled this just fine. I was wondering if anyone else has noticed this as well.

[kovidgoyal]

0.6 tries to more faithfully replace the formatting in the source HTML. It's likely that your source html has its contents either ina table or with large margins.

[JvdW]

Originally Posted by kovidgoyal

0.6 tries to more faithfully replace the formatting in the source HTML. It's likely that your source html has its contents either ina table or with large margins.

On, maybe, a related question:
Does Calibre preserve the existing CSS information when converting for example from a zipped html source to ePub?
From the question it might be obvious that I'm expericing problems with that and have resorted to using Sigil for converting html+css to epub.

Regards,

Joop

[gwynevans]

Originally Posted by slantybard

Okay, I have noticed on some of my zipped html books that ePub conversion in 0.6xx produces ePubs with the body text "squished" into about an inch of the middle of the screen on my 505. Previously, the conversions using the 0.5xx series of calibre handled this just fine. I was wondering if anyone else has noticed this as well.

Actually, I have...

When I've seen it, it's been with a MS Word generated HTML file, and right at the end of the in-line CSS, there's been this...

@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}

The problem is that the viewer's honoring the "margin:1.0in 1.25in 1.0in 1.25in;", specifically the 1.25 inch left & right margins! I don't know why Calibre now passes it whereas before it stripped it, but one work around is to edit the HTML and delete the section above, although you could try just passing "div.Section1 {}" in Calibre's CSS override box. (Not tested)

[kovidgoyal]

Yes, calibre does preserve CSS.

[JvdW]

Originally Posted by kovidgoyal

Yes, calibre does preserve CSS.

Then the epub generated by Sigil should be the same as the one generated by Calibre, right? (I haven't touched the custom CSS part or the remove empty lines stuff)

Joop

[kovidgoyal]

calibre does perform some transforms on the CSS, as I'm sure Sigil must as well.

[user_none]

Originally Posted by JvdW

Then the epub generated by Sigil should be the same as the one generated by Calibre, right?

Nope. Sigil pushes all CSS into the top of the HTML file for editing. This can result in css from multiple files being combined for unexpected results. See Issue 58 for an example of how it combines and produces multiple style settings for the same entry. Only one will be used, not necessarily the one you want.

[JvdW]

Originally Posted by user_none

Nope. Sigil pushes all CSS into the top of the HTML file for editing. This can result in css from multiple files being combined for unexpected results. See Issue 58 for an example of how it combines and produces multiple style settings for the same entry. Only one will be used, not necessarily the one you want.

Thanks for the info and Sigil and combining various CSS styles. I'll try to come up with a simple example of what Calibre does with CSS that I think shouldn't happen.

Joop