Originally Posted by Peter Sorotokin
Th limit is there because we cannot paginate the content starting from the beginning of the chapter fast enough if someone navigates to the end of the chapter (e.g. through TOC). But if we have some known page breaks in the chapter we can start from those. If the chapter is too long, we just insert them heuristically (in future we may start paying attention to page-break CSS properties). In some sense it is the same startegy that converters have to do, but done on the device itself - and the artifacts are the same (artificial page breaks). Still, it's better than dropping CSS altogether IMHO.
Important consideration here is that XML parsing and CSS cascade can be done fast enough even for very large chapters (although we have not squeezed everything there by any means). Layout and rendering are much slower part. However rendering only needs to be done for a single page, so it is almost always layout which causes the most problems when navigating in the middle of the chapter. (Sequential reading performance considerations are different).
|