No more 300k limit per flow on latest DE SDK ?

[Hadrien]

Originally Posted by Peter Sorotokin

This limit is configured by individual manufacturers. It depends on the CPU speed and memory. Software improvements will also allow us to push it higher - but those did not filter down into devices yet. Going forward, I expect this limit won't be of much practical importance.

However, breaking content into chapters if content has logical breaking points is always going to work better - no matter how high the limit is.

Peter

Sure, but the problem is when you don't have logical breaking points (like with Proust).

So basically, what you mean is that the other manufacturers decided to remove the limit or opted for a much higher limit ?
What I'd really like to know is if the support for either a higher limit or no limit at all will make it onto the PRS-505/700. Otherwise it'll force content providers to use 300k flows for legacy support.

[Peter Sorotokin]

Originally Posted by kovidgoyal

Interesting, so rendering happens in page blocks?

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).

[Peter Sorotokin]

Originally Posted by Hadrien

Sure, but the problem is when you don't have logical breaking points (like with Proust).

I only keep repeating it so no one gets false impressions.

BTW, do you have those Proust EPUB files somewhere? It seems that everyone obeys 300k limit now and it is getting hard to find content which does not.

So basically, what you mean is that the other manufacturers decided to remove the limit or opted for a much higher limit ?
What I'd really like to know is if the support for either a higher limit or no limit at all will make it onto the PRS-505/700. Otherwise it'll force content providers to use 300k flows for legacy support.

I would check what they did by trying it. For instance, they may have removed it only to make such content unusable in other way (e.g. device freezing or crashing).

[kovidgoyal]

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).

Ah, makes sense, thanks.

[Hadrien]

Originally Posted by Peter Sorotokin

I only keep repeating it so no one gets false impressions.

BTW, do you have those Proust EPUB files somewhere? It seems that everyone obeys 300k limit now and it is getting hard to find content which does not.

Try Ulysses: http://www.feedbooks.com/book/1232.epub

[Jellby]

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 in normal reading, one starts from the beginning and reads page by page until the end. Could that be done without the spurious page breaks? If the book is closed and then opened again to resume reading in the middle of a long "chapter", could it be done so that whatevere spurious pagebreaks needed appear only in the pages before the current position? The point is to provide a smooth reading experience, even if small inconsistencies are introduced when jumping back and forward.

[Peter Sorotokin]

Originally Posted by Hadrien

Try Ulysses: http://www.feedbooks.com/book/1232.epub

Aha, thanks. This is the type of the file that I was looking for. BTW, were extra line breaks inserted in the last "paragraph"?

[Peter Sorotokin]

Originally Posted by Jellby

But in normal reading, one starts from the beginning and reads page by page until the end. Could that be done without the spurious page breaks? If the book is closed and then opened again to resume reading in the middle of a long "chapter", could it be done so that whatevere spurious pagebreaks needed appear only in the pages before the current position? The point is to provide a smooth reading experience, even if small inconsistencies are introduced when jumping back and forward.

Certainly it is possible to do it this way, but the logistics are getting just too complex for such an obscure feature. We need to break 300k limit, but there is no reason to do it in a fancy way. I'd rather do things like text/layout quality and hyphenation first.

Peter

[Valloric]

Originally Posted by Peter Sorotokin

I'd rather do things like text/layout quality and hyphenation first.

By all means, give those a higher priority.