MobileRead Forums - View Single Post - Large files: parts have different formatting, hard page break

Dyspeptica · 10-14-2012, 05:46 PM

" Doctor Oh: This is by design, as the memory and processor speed is limited. The ePub (most use the Adobe Digital Editions) engine requires the epub to be in chunks smaller than 300k. To be safe calibre uses 260k as the guide. If the chucmk ends up above 300k many readers will lock-up."

Thanks. This confirms something I read somewhere. I have no problem with this generally, although I would like to avoid it, if I could.

"Use Sigil and manually insert breaks at the end of chapters. As long as the chapters are less than 300k you will be fine."

Doppelganger recommended sigil as well, but I cannot get it to build on Fedora 17. It has a problem finding the boost libraries when linking. I'll post on sigil's forums about that.
If I get that fixed I will be happy to try sigil... but I have no idea if it can be run from the command line. I have a large number of files to convert, which I am presently doing by script, not in the calibre gui.

There ARE no chapters. These are large single files.
Doppelganger stated "You can change the limit in epub output options". I am presently unable to see exactly where that can be done (noting that I am using convert from the command line. The man pages give me no joy on this point. Can someone give me a clue?
If I can change the limit, I will. Does anyone know if stanza and fbreader have the 300k limit problem?

"There is nothing in calibre that will cause this to happen. The original html needs to be examined closer to see exactly how the font info is applied."

Well it IS happening and there are no font directive changes at the break points. That's why the change is so weird/annoying.

"The sections do not have their own default. The css controls all aspects of the epub the same way css controls the html. Make sure your original css is correct."

I'm not actually *using* css. I just pushed some (I know, now deprecated) html font size directives at the top. I can create a 'standard.css' file and call that instead of putting in html, but I fail to see how/why that would be different *unless* the convert code remembers that there is a css directive file, and *re-loads* the css.
Can anyone confirm/deny this?

"You might get better guidance from the folks in the Sigil forum."

Hope so! As noted, I already have a problem getting sigil to compile.

"Good Luck"

I think I need it! None of this is fatal but it is annoying.

10-14-2012, 05:46 PM	#4
Dyspeptica Enthusiast Posts: 27 Karma: 10 Join Date: May 2012 Device: iPad	" Doctor Oh: This is by design, as the memory and processor speed is limited. The ePub (most use the Adobe Digital Editions) engine requires the epub to be in chunks smaller than 300k. To be safe calibre uses 260k as the guide. If the chucmk ends up above 300k many readers will lock-up." Thanks. This confirms something I read somewhere. I have no problem with this generally, although I would like to avoid it, if I could. "Use Sigil and manually insert breaks at the end of chapters. As long as the chapters are less than 300k you will be fine." Doppelganger recommended sigil as well, but I cannot get it to build on Fedora 17. It has a problem finding the boost libraries when linking. I'll post on sigil's forums about that. If I get that fixed I will be happy to try sigil... but I have no idea if it can be run from the command line. I have a large number of files to convert, which I am presently doing by script, not in the calibre gui. There ARE no chapters. These are large single files. Doppelganger stated "You can change the limit in epub output options". I am presently unable to see exactly where that can be done (noting that I am using convert from the command line. The man pages give me no joy on this point. Can someone give me a clue? If I can change the limit, I will. Does anyone know if stanza and fbreader have the 300k limit problem? "There is nothing in calibre that will cause this to happen. The original html needs to be examined closer to see exactly how the font info is applied." Well it IS happening and there are no font directive changes at the break points. That's why the change is so weird/annoying. "The sections do not have their own default. The css controls all aspects of the epub the same way css controls the html. Make sure your original css is correct." I'm not actually using css. I just pushed some (I know, now deprecated) html font size directives at the top. I can create a 'standard.css' file and call that instead of putting in html, but I fail to see how/why that would be different unless the convert code remembers that there is a css directive file, and re-loads the css. Can anyone confirm/deny this? "You might get better guidance from the folks in the Sigil forum." Hope so! As noted, I already have a problem getting sigil to compile. "Good Luck" I think I need it! None of this is fatal but it is annoying.