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

Quote:

Originally Posted by MacEachaidh

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

Quote:

Originally Posted by AlPe

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

Quote:

Originally Posted by MacEachaidh

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.

05-14-2013, 04:19 AM	#1
MacEachaidh Browser Posts: 745 Karma: 578294 Join Date: Apr 2010 Location: Australia Device: Kobo Touch, Kobo Aura HD	Debugging an epub anomaly? 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?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Anomaly: a different kind of litfic	theapatra	Self-Promotions by Authors and Publishers	0	05-12-2012 07:36 AM
Remove Books anomaly?	unboggling	Calibre	31	10-24-2011 08:15 PM
Kobo pooched - screen anomaly	Deerslayer	Kobo Reader	7	04-26-2011 08:29 AM
Classic Anomaly with Trook and Nook?	jhempel24	Nook Developer's Corner	0	11-28-2010 12:19 PM
image zoom anomaly in iBooks	whbenson	Apple Devices	1	09-13-2010 10:51 AM

05-14-2013, 04:34 AM	#2
Doitsu Grand Sorcerer Posts: 5,680 Karma: 23983815 Join Date: Dec 2010 Device: Kindle PW2	Maybe the .html file contains some non-printable control characters that most readers ignore. Try deleting all white-space characters between the paragraphs.

05-14-2013, 05:24 AM	#3
MacEachaidh Browser Posts: 745 Karma: 578294 Join Date: Apr 2010 Location: Australia Device: Kobo Touch, Kobo Aura HD	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.

05-14-2013, 06:31 AM	#4
pdurrant The Grand Mouse 高貴的老鼠 Posts: 73,596 Karma: 315126578 Join Date: Jul 2007 Location: Norfolk, England Device: Kindle Oasis	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.

05-14-2013, 10:37 AM	#7
theducks Well trained by Cats Posts: 30,889 Karma: 59840450 Join Date: Aug 2009 Location: The Central Coast of California Device: Kobo Libra2,Kobo Aura2v1, K4NT(Fixed: New Bat.), Galaxy Tab A	@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.

05-14-2013, 11:29 AM	#8
MacEachaidh Browser Posts: 745 Karma: 578294 Join Date: Apr 2010 Location: Australia Device: Kobo Touch, Kobo Aura HD	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.

05-15-2013, 01:00 AM	#10
pholy Booklegger Posts: 1,801 Karma: 7999816 Join Date: Jun 2009 Location: Toronto, Ontario, Canada Device: BeBook(1 & 2010), PEZ, PRS-505, Kobo BT, PRS-T1, Playbook, Kobo Touch	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.

05-15-2013, 06:01 AM	#11
davidfor Grand Sorcerer Posts: 24,905 Karma: 47303824 Join Date: Jul 2011 Location: Sydney, Australia Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos	@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.

05-15-2013, 11:29 AM	#12
JSWolf Resident Curmudgeon Posts: 79,005 Karma: 144284074 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	I believe it is a bug if it's a rather long paragraph.

05-17-2013, 09:17 PM	#13
pholy Booklegger Posts: 1,801 Karma: 7999816 Join Date: Jun 2009 Location: Toronto, Ontario, Canada Device: BeBook(1 & 2010), PEZ, PRS-505, Kobo BT, PRS-T1, Playbook, Kobo Touch	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.

Advert

Advert