Mobile ADE TOC limitation?

[brewt]

Does anyone know what the practical limitation to the number of items there is to the number of table of content entries in Moble ADE might be (as in, say, maybe a nook or a sony reader)? I've built a book that has, say, oh, about 150 entries or so, lots of pictures, and my Sony 350 Reader cannot bring up the TOC, no matter how long I wait. It can open the book, and as long as I just read it, front to back, it seems fine. The trouble is when I want to skip around. Yeah, it's poetry.
Not the same in desktops, not the same in iBooks; both those can open the book and the TOC just fine.
Also: How 'bout the number of hyperlinked footnotes? I also have a heavily footnoted book that won't open at all on the reader: Just fine on desktop.
And sorry, no, I can't post the examples.
-Brewt

[Toxaris]

I never heard of a limit. Does it validate?

[brewt]

Originally Posted by Toxaris

I never heard of a limit. Does it validate?

Of course not. Hasn't mattered too much in smaller books.

[DiapDealer]

Originally Posted by brewt

Of course not. Hasn't mattered too much in smaller books.

I'm going to use this for my new sig quote.

Help! It won't work.
Does it validate?
Of course not, why would that matter?

[brewt]

Originally Posted by DiapDealer

I'm going to use this for my new sig quote.

Help! It won't work.
Does it validate?
Of course not, why would that matter?

You are my hero.

But seriously: A 150 chapter epub that does validate: do you have one that the toc opens within our lifetime on mobile ADE? Because if that's the problem, I can fix that; I don't think that's the problem. Because it opens just fine in iBooks and Desktop ADE on multiple operating systems, not to mention calibre. If it were simply a lowest common denominator problem (which I have succeeded in violating on other projects in spectacular ways with better results) then shouldn't something else hint at it? It almost feels like there's a resource stack limitation I'm hitting up against on a memory-restrictive device. Yes, there's a limitation of around 30-megs for an epub according to spec; I've built books that come in at about 1/2 that with no images and maybe that's part of the problem here: I haven't run any kind of image cleaners beyond what word/dreamweaver do (which showed them just fine, as well as desktop epub readers). Surely, I'm not the only person out here who is trying to assemble such big-ass things. I've gotten 10,000 page files to open in Mobile-ADE; this one feels different, and the difference I can point to is the number of TOC entries.

Nothing besides "We don't know we've never tried anything like that but it doesn't validate that must be it therefore we can't help you?" I'm totally willing to admit I am pur-a-dee wrong (gosh, have I been that before? Let me think...) but given the number of times I have totally botched things before, this one seems to be different. Fixing validation hasn't made that many of my problems go away in the past, which is, I'm sure, why I'm not so quick to bow down to it.

-b

[DiapDealer]

150 entries doesn't sound like an outrageous amount of ncx entries to me, but no, I've never created an ebook that had an ncx that even approached that number of entries. Are they in collapsible/nested "sections" or is everything in the TOC on one level?

And for the record... as frustrating as "does it validate" might be for you, it's still the easiest/sanest way to start troubleshooting. Especially if you're looking to bring in outside help. Validation provides a "ground zero"... everybody is starting on the same page. Otherwise, there's too many unknown variables for anyone to be able to methodically eliminate/determine problem areas. Especially with no actual code to vet.

So that's where we're at: I don't know of any hard limits for the number of NCX entries (that only affect the mobile RMSDK), and even if there were... I doubt highly that 150 entries would be in violation of that limit. So we're right back to "what might be wrong with the code?" And since you can't share the code, what we have to work with is that your ePub doesn't validate. *shrugs*

[brewt]

Nested: 2 levels.
Thanks, and that's what makes me think it's something device specific: it totally opens on the desktop where there are more resources. And the apple readers I have access to do things differently anyway. I'm not convinced there's an actual ncx-entry-number limitation; it almost feels like (as I watch the spinning just-sit-there-and-wait graphic slow down until it stops) there's some kind of memory allocation limitation. Which I'll bet Sony isn't going to be in a bit fat hurry to fix. Dagnabit.
I can fix things in other ways: by cutting my complete-works-of-so-and-so into multiple volumes for epaper (or at least, the one I have). It just irks me: the overall file is only 6 megs.
My heavily-footnoted book has a similar number of hyper-texted linked up notes; that's what got my attention here.
Thanks. If I run into it again, I'll spin up some abstracted models I can post.
-b

[Jellby]

Originally Posted by brewt

A 150 chapter epub that does validate: do you have one that the toc opens within our lifetime on mobile ADE?

Yes, "Les misérables" (available in the MR library) has more than 300 chapters, it validates and opens with no problems in my Orizon (using mobile ADE).

It almost feels like there's a resource stack limitation I'm hitting up against on a memory-restrictive device. Yes, there's a limitation of around 30-megs for an epub according to spec

The spec mentions no limit, and I've also read without problems books of more than 30 MB. But some devices apparently use an older version of ADE which has some limits on the size of the "chapters" (something like 300 KB uncompressed and 100 KB compressed, if I remember correctly).

Are you sure the problem is the number of TOC entries? Couldn't it be some error in the NCX file? something that other software manages to ignore but not ADE? This is where validation is useful.

Fixing validation hasn't made that many of my problems go away in the past, which is, I'm sure, why I'm not so quick to bow down to it.

Validation is not a magic wand, but if a file validates, you can discard errors is the code, whereas if it doesn't, you should at least check whether the reasons for not validating may be related to your problem.

[Toxaris]

I have created books in the past with 150+ entries in the toc in multiple levels. Never had an issue on my Sony readers in loading the TOC. It might be a memory thing. Have you tried loading the TOC at different locations (cover, titlepage, small chapter, large chapter)? I believe the Sony will load in one XHTML file at the time. If that is already stretching towards the 300kb, it might be that it will have difficulties with the TOC.

Also, I understand your frustration, but as DiapDealer said, we must have a starting ground. You would be surprised how many 'problems' we see here on and outside the forum which in fact are not really problems/bugs but just plain errors which will turn up by validating.

[mrmikel]

The errors can be as simple as errors in case. Engines are NOT all the same. Browsers and their derivatives ignore errors that bring ebooks to a complete halt. There is an epub bible on here somewhere and I am sure it has a significant index, so I too doubt memory problems.

Maybe there are hidden images or page numbers in the toc which are taking forever to load and which contribute nothing.

[JSWolf]

I might know what the problem is. If your ToC is using anchors, the reader has to parse the anchors before it displays the ToC. Calibre used to make a ToC with anchors and that did slow down displaying a normal sized ToC.

So if your ToC is setup like file.hmtl#ch03 then it will take a very long time to parse 150+ ToC entries.

[brewt]

Originally Posted by JSWolf

I might know what the problem is. If your ToC is using anchors, the reader has to parse the anchors before it displays the ToC. Calibre used to make a ToC with anchors and that did slow down displaying a normal sized ToC.

So if your ToC is setup like file.hmtl#ch03 then it will take a very long time to parse 150+ ToC entries.

By golly, JSWolf, you might have something there:

<navPoint id="d188731f-fff1-4113-8b7f-adde75ad8c2a" playOrder="147">
<navLabel>
<text>In My Hands (159 words)</text>
</navLabel>
<content src="20111206%20In%20My%20Hands1.htm#calibre_toc_1 48"/>
</navPoint>

This was off a fresh build in calibre, so I've could have something mis-check-marked in it. Not quite sure which one it is, though, as it is calibre that is inducing the anchor:

<title id="calibre_toc_148">In My Hands (159 words)</</title>


Have I mentioned how clever you are lately, btw? Thanks for looking...
-b

[Hitch]

Originally Posted by brewt

By golly, JSWolf, you might have something there:

<navPoint id="d188731f-fff1-4113-8b7f-adde75ad8c2a" playOrder="147">
<navLabel>
<text>In My Hands (159 words)</text>
</navLabel>
<content src="20111206%20In%20My%20Hands1.htm#calibre_toc_1 48"/>
</navPoint>

This was off a fresh build in calibre, so I've could have something mis-check-marked in it. Not quite sure which one it is, though, as it is calibre that is inducing the anchor:

<title id="calibre_toc_148">In My Hands (159 words)</</title>


Have I mentioned how clever you are lately, btw? Thanks for looking...
-b

We have a massive medical volume which has over 1700 epub "pages" (by ADE's count, so....1,700,000 chars?) and hundreds of TOC entries, nested down to 3 tiers. I don't actually remember how many TOC entries, in total, exist, but it's more than 150, and I haven't run into any issues with it yet. I don't know what type of issues you'll run into with Calibre, though.

Hitch

[JSWolf]

Originally Posted by brewt

By golly, JSWolf, you might have something there:

<navPoint id="d188731f-fff1-4113-8b7f-adde75ad8c2a" playOrder="147">
<navLabel>
<text>In My Hands (159 words)</text>
</navLabel>
<content src="20111206%20In%20My%20Hands1.htm#calibre_toc_1 48"/>
</navPoint>

This was off a fresh build in calibre, so I've could have something mis-check-marked in it. Not quite sure which one it is, though, as it is calibre that is inducing the anchor:

<title id="calibre_toc_148">In My Hands (159 words)</</title>


Have I mentioned how clever you are lately, btw? Thanks for looking...
-b

<content src="20111206%20In%20My%20Hands1.htm#calibre_toc_1 48"/>

Will have to become

<content src="20111206%20In%20My%20Hands1.htm"/>

All the ToC entries that don't need the anchors, remove the anchors.

[Toxaris]

Another reason not to use Calibre for conversions...