View Full Version : Debugging an epub anomaly?


MacEachaidh
05-14-2013, 04:19 AM
I'm fairly new to epub formatting, and so far my issues have been few, but I've hit a speed-hump that's befuddling me, and I'd appreciate any suggestions as to how to resolve it.

I've created an epub that functions perfectly, *except* at one specific point, where an uncoded pagebreak occurs not in ADE, not in the latest version of Sigil, but in my eReader (a Kobo Touch with 2.5.1 firmware). And when I page through the book on my Kobo, accessing that one page is always extremely slow, when the rest of the book isn't.

It behaves as if there's some hidden code at that point. Is that even possible? If I change the font size in the Kobo, so that the pagination falls differently, then the page still breaks at that same point a paragraph break at the end of a five-line paragraph every time. I've made an edited version of the epub, containing only two paragraphs the one before the break and the one following and it still reads with a page break at that point.

I've visually checked the code in Sigil: I can see nothing unexpected. The coding is very simple there: only a paragraph style, with no inherited values or character codes. I've validated the CSS in the W3C validation page, and it passed with no issues; ditto the epub itsef in Sigil's inbuilt FlightCrew, with no errors found. The fault could conceivably be with Kobo's firmware, but there must be something at that point to trigger it, since it happens nowhere else in the book.

I'm stumped. Any suggestions, please?

Doitsu
05-14-2013, 04:34 AM
Maybe the .html file contains some non-printable control characters (http://en.wikipedia.org/wiki/Control_character) that most readers ignore.
Try deleting all white-space characters between the paragraphs.

MacEachaidh
05-14-2013, 05:24 AM
Ah, Doitsu, thanks so much for the suggestion. :)

I had no idea control codes could survive in HTML. Not invisibly, anyway. I've done a test version of the epub, removing all but the one chapter where the problem occurs; it still happens. I then whittled that down, removing all text from the chapter except the ten or so logical pages before that point, and the remaining ten or so pages in the chapter after that point: the problem goes away.

With the copy of the chapter that has the problem, I've manually edited it in Sigil and removed all the spaces between the paragraphs; the problem hasn't gone away.

I'm really scratching my head with this.

pdurrant
05-14-2013, 06:31 AM
It's possible that it's a bug in the Kobo rendering algorithm. I suggest looking at the HTML file with a hex editor just to check that there's nothing unexpected hiding there.

AlPe
05-14-2013, 08:07 AM
It behaves as if there's some hidden code at that point. Is that even possible? If I change the font size in the Kobo, so that the pagination falls differently, then the page still breaks at that same point a paragraph break at the end of a five-line paragraph every time. I've made an edited version of the epub, containing only two paragraphs the one before the break and the one following and it still reads with a page break at that point.

Is the second paragraph quite long? It is known that Kobo firmware, instead of splitting a long <p> in the middle (filling the current "page"), postpones it all together on the next "page". (Someone argued it is a problem with Adobe RMSDK, worsened by Kobo firmware, but I cannot confirm this lead.)

This occurs more often when the font height is set to large values (because the long <p> requires even more lines), but I personally encountered this problem even with small fonts, for very long <p>'s.

MacEachaidh
05-14-2013, 10:16 AM
Is the second paragraph quite long? It is known that Kobo firmware, instead of splitting a long <p> in the middle (filling the current "page"), postpones it all together on the next "page". (Someone argued it is a problem with Adobe RMSDK, worsened by Kobo firmware, but I cannot confirm this lead.).
Hi APe, thanks for the thoughts.

No, the next para is quite short. But I recognise the action you're referring to, and yes my understanding is that it's an ADE thang as well. I sidestep it, by setting widows and orphans to zero at the top of the CSS, and I don't set line height or font size directly in my epubs I leave that to settings in the eReader itself.

But I think I've found what the problem is: Kobo seems to have decided that that chapter alone was simply too long. I know about keeping chapters short, and that's somethign I generally do, but in this case there was no place to logically break it (without creating a spurious page break in the Reader, which is what I was trying to resolve anyway! ;) ) The section was 108 logical pages long, and my Kobo just seems to have given up after about 90 pages and forced it into a pseudo-section break off its own bat.

Puzzling, because I've seen other worse-formatted spubs even commercial ones! with single sections longer than that.

May be a limitation of Kobo's code parsing.

Anyway, thanks folks APe, pdurrrant, Doitsu for your help. :)

theducks
05-14-2013, 10:37 AM
@Mac
You might explore style settings for Widows and Orphans an see if any combination produces a more pleasing result if you can't eliminate the break all together.

MacEachaidh
05-14-2013, 11:29 AM
Hey ducks,
Yeah as I said, I habitually set widows and orphans to zero, largely because I dislike erratically-lengthed pages and, as APe mentioned, the Kobo is averse to breaking paragraphs nad sometimes breaks text after only a half a page.

Not sure how common that is — the only other eReader I've owned was an iRiver, and that did the same thing, so maybe it's a behaviour of ADE on some devices that use it. The zero setting gives me even-length pages ... for the most part. There's still a few Kobo idiosyncracies — like its habit of flicking the last line of a chapter, if it falls on the last line of a display page, over to the next page, where it sits on its purposeless lonesome.

DaleDe
05-14-2013, 04:48 PM
Hey ducks,
Yeah as I said, I habitually set widows and orphans to zero, largely because I dislike erratically-lengthed pages and, as APe mentioned, the Kobo is averse to breaking paragraphs nad sometimes breaks text after only a half a page.

Not sure how common that is the only other eReader I've owned was an iRiver, and that did the same thing, so maybe it's a behaviour of ADE on some devices that use it. The zero setting gives me even-length pages ... for the most part. There's still a few Kobo idiosyncracies like its habit of flicking the last line of a chapter, if it falls on the last line of a display page, over to the next page, where it sits on its purposeless lonesome.

ADE does limit the size of the file containing a chapter and will break it if it is too large. Calibre also has such a setting. Generally a 100K compressed or about 300K expanded is the limit for a file size containing text. The reason is that a full file must be pulled into RAM all at once and some readers have a limited amount of RAM storage. You may want to examine, not the number of pages, but the file size. This is the determining factor.

Dale

pholy
05-15-2013, 01:00 AM
I'm working an epub which puts a <div> around all the paragraphs of a chapter. If the chapters are large my Sony T1 slows down in page turning near the end. I also have one case where I see an unexpected page break. I will try removing the surrounding <div> to see if that cleans things up.

davidfor
05-15-2013, 06:01 AM
@MacEachaidh: Any chance of a file to test? I suspect the size idea is what's happening, but I have constructed a couple of epubs with bigger than average files to see what happens. So far, the only issue seems to be that page turns at the end are much slower than at the start.

JSWolf
05-15-2013, 11:29 AM
I believe it is a bug if it's a rather long paragraph.

pholy
05-17-2013, 09:17 PM
Well, I removed the enclosing <div> from each chapter, and all the classless spans from paragraphs. Now the big file is just over 200K uncompressed, and I still have that unexpected page break - in a different place, although possibly the same number of bytes from the start.
So I'm inclined to think there's a bug in the Sony T1 software.