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

[Hadrien]

I've seen several reports that the new SDK doesn't force a 300k limit per flow anymore. Currently on the homepage, the review of the Cool-er states that the limit doesn't seem to apply anymore, I've seen a tweet saying that new PRS-505 devices didn't have this limit and when I tested the Cybook Opus, Michael from Bookeen said that as far as he could remember, such a limit doesn't exist anymore.

Is there any official confirmation about this from Adobe (Peter ?) or someone working with their SDK ?

What about the older PRS-505 and PRS-700 ? Will Sony provide an upgrade to disable the limit and enable justified text ? It would be a very bad thing to keep the market fragmented: some books (such as Ulysses) need to have flows that are longer than 300k and while we should continue to divide e-books into multiple flows as much as possible, it would be a good thing to get rid of this limit.

[HarryT]

A related question: if you use a tool such as Calibre to convert, say, a MobiPocket book to ePub, will it automatically split the file into 300k "flows"? The reason I ask is that I create all my books as one single HTML file, and it would be a great deal of work to have to manually split them up.

[Hadrien]

Originally Posted by HarryT

A related question: if you use a tool such as Calibre to convert, say, a MobiPocket book to ePub, will it automatically split the file into 300k "flows"? The reason I ask is that I create all my books as one single HTML file, and it would be a great deal of work to have to manually split them up.

It will and Calibre will try to use the h1/h2/h3 tags as much as it can to do so.
For Feedbooks, our script is based on Xpath expressions to divide a source HTML into multiple flows (parts, chapters, sections and text flows). They're both quite similar from a user perspective, except that we don't force flows to be 300k long.

[HarryT]

Thank you, Hadrien, that's good news.

If it is indeed true that the 300k flow limit has gone from devices which use the ADE SDK, the Sony devices could very soon find themselves the "orphans" of the ePub world, unable to read books which other ePub devices are able to handle.

[Hadrien]

Originally Posted by HarryT

If it is indeed true that the 300k flow limit has gone from devices which use the ADE SDK, the Sony devices could very soon find themselves the "orphans" of the ePub world, unable to read books which other ePub devices are able to handle.

And justified text.
That's why Sony and Adobe should absolutely provide an update to avoid this whole mess.

[kovidgoyal]

What needs to be checked is if the new SDK encounters a large flow does it use the full HTML+CSS rendereer or a simplefied renderer for speed. I doubt the Cooler has a much faster processor than the 700.

[mtravellerh]

Originally Posted by kovidgoyal

What needs to be checked is if the new SDK encounters a large flow does it use the full HTML+CSS rendereer or a simplefied renderer for speed. I doubt the Cooler has a much faster processor than the 700.

I think it was a memory problem more than a speed problem, honestly. All of the Gutenberg ePub files I have tried so far have worked on the Cool-ER, so far ( a bit yucky to go through them, but that's the price for scientific research for you!) No speed issues, either! Please throw some "problematic" ePubs my way and I will test them!

[kovidgoyal]

According to Peter, it was a speed problem. Since he helped write the software, I'm inclined to take his word for it

If it was a memory problem, then there should still be a limit, it will just be larger.

It should be easy to generate a test epub using a simple script that outputs something like

<p>
line 1<br/>
line2<br/>
...
</p>

Then just convert it to epub using calibre (with splitting turned off --profile none)

[mtravellerh]

Cool-ER has a Samsung S3C2440 ARM 400MHz Processor and 128 mb RAM. I think Sony 700 is about the same (400MHz Freescale and 128 mb, if I remember right) So that puts them on par hardwarewise.

[mtravellerh]

Originally Posted by kovidgoyal

According to Peter, it was a speed problem. Since he helped write the software, I'm inclined to take his word for it

Yes, I believe that. But I guess the problem should have been the 505, then! Isn't the ADE engine on the Sonys pretty much identical? ( the 505 features a staggering 200 MHz processor and 64 mb RAM)

[kovidgoyal]

Originally Posted by mtravellerh

Cool-ER has a Samsung S3C2440 ARM 400MHz Processor and 128 mb RAM. I think Sony 700 is about the same (400MHz Freescale and 128 mb, if I remember right) So that puts them on par hardwarewise.

That would lead me to believe the SDK is swapping in a simpler renderer for large flows

[Peter Sorotokin]

Originally Posted by Hadrien

I've seen several reports that the new SDK doesn't force a 300k limit per flow anymore. Currently on the homepage, the review of the Cool-er states that the limit doesn't seem to apply anymore, I've seen a tweet saying that new PRS-505 devices didn't have this limit and when I tested the Cybook Opus, Michael from Bookeen said that as far as he could remember, such a limit doesn't exist anymore.

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

[Peter Sorotokin]

Originally Posted by kovidgoyal

What needs to be checked is if the new SDK encounters a large flow does it use the full HTML+CSS rendereer or a simplefied renderer for speed. I doubt the Cooler has a much faster processor than the 700.

No, that stuff is not out yet. However, the strategy is going to be not a simpler engine, but insertion of forced page breaks.

[kovidgoyal]

Originally Posted by Peter Sorotokin

No, that stuff is not out yet. However, the strategy is going to be not a simpler engine, but insertion of forced page breaks.

Interesting, so rendering happens in page blocks?

[Hadrien]

Originally Posted by kovidgoyal

Interesting, so rendering happens in page blocks?

I think that what Peter meant is that when they reach a certain limit, they stop parsing the file and consider it finished (closing the XML tags), and then start parsing the rest of it like a new flow.