Odd occurance with Sigil & Calibre
 

I had an odd occurance with (only) some of the files I converted to Epub using Calibre and then opened with Sigil. Although the Adobe Digital Editions displayed the Epub correctly (at least like I thought was correctly), Sigil displayed it with all the body text centered instead of justified.

Any ideas why? Other ebooks in the same series and done with the same batch in Calibre, displayed correctly in Sigil.

Known problem.
I'm not an expert but according to the ticket it has to do with conflicting css or some such.

Look in the Code View. There is probably a @page CSS rule with a "text-align: center;" style. Calibre uses this to center cover pages. The problem is that when this style gets copied from this one XHTML file with the cover to the one flow used in Sigil, all of your text becomes centered.

So just delete this @page rule and your fine.

This and other problems relating to Sigil not rewriting your CSS on input to be compatible with a single-flow editing environment will not be fixed until 0.2.0, which will be the first release of Sigil with a new multi-flow editing approach. Since this will involve a massive redesign, it's probably at least a month away, if not more.

Until then you'll have to fix such problems by hand.

:thanks:

That's fast! Seeing as it is marked as low priority (the ticket) I thought it would take much longer. Thanks!

The ticket is not the cause of the redesign (although I agree, I should create one for it). The cause is performance.

I was aware that I will probably have to write a CSS parser/rewriter and include it as an option on ebook imports with some sort of dialog when the user loads something in. Not something I looked forward to, but it would be necessary.

But what finally pushed me to decide to redesign the UI and the entire editing environment away from the One True Flow™ to one respectful of the original XHTML file arrangement in epubs is WebKit's abysmal performance with large flows. During Sigil's development, I failed to take into account all the various dreadfully coded HTML streams people would be importing. Of course, I took into account that people would be importing incorrect HTML (hence the integration of Tidy), but not stuff filled with flat-out useless junk. Just using sane HTML not only vastly improves CPU utilization but memory consumption too, as this thread illustrates.

I didn't fully consider the ramifications of that. Of course, during testing I mostly used my own, respectably coded ebooks. These worked fine. I also looked for badly coded ebooks, and while performance was lower, it all still worked respectably on my machine.

Then again, my main machine is a rather high-end quad-core with 8 GB of RAM. But even on my low-end five-year-old laptop the "bad" books could be edited rather nicely. But it seems I don't know just how bad "bad" can be. And from the reports, issue attachments and emails of users experiencing poor performance, "bad" can sometimes mean "really, really BAD".

And it's not like I can blame the WebKit devs. No browser is expected to perform well with files with 50k lines of XHTML, no matter the quality of the code. It's just not meant to.

So to improve performance, the redesign is necessary. I'm just saddened that I didn't realise this before the first release, because then you nice people wouldn't have to suffer through this. I still believe the One True Flow idea is nice for usability and user-friendliness, but alas, I'll just have to find a better way to achieve those goals.

The CSS issue will merely be fixed as a consequence of this new architecture, since styles will no longer conflict: flow-specific CSS will stay in those flows.