Bug of the long paragraph

[tartanpion]

How long will it take to update their version of adobe to overcome this major bug in reading. I've been waiting since firmware 2.1.5 and hope and desire to renew my trust in kobo disappears...

[treadlightly]

I agree. I personally feel this should be at the top of their bug-fix priority list. This and the (related?) "random stray sentence at the end of chapters" bug. At a glance at the page, you think you are at chapter's end, and then whoops! just foolin' with ya!

[DNSB]

Originally Posted by tartanpion

How long will it take to update their version of adobe to overcome this major bug in reading. I've been waiting since firmware 2.1.5 and hope and desire to renew my trust in kobo disappears...

Looking at the "About Kobo Aura HD", it says the Reader Mobile software is copyright by Adobe 1995-2013. Complaints to Adobe might be more to the point than complaints to Kobo. Though if you think Kobo does not respond well to bug reports, try Adobe for sheer indifference.

Regards,
David

[ShellShock]

And even if Adobe did fix this bug, how confident are we that a new release of Adobe reader mobile would not contain new bugs? Kobo probably cannot devote a lot of resources to a full regression test, so they probably prefer to direct effort to kepub support instead, i.e., where they control the software development.

[PeterT]

Just because the copyright says 1995-2013 it does not mean that they are using updated versions of the engine; for all we know they are still using code from 2010..

And as an example of what I see in many books, here is an excerpt from Finding Oz: How L. Frank Baum Discovered the Great American Story by Evan I. Schwartz. Near the end of a chapter I get the following:

Page that ends (near the bottom) with a paragraph:
Imparting this same lesson, Frank Baum's Wizard finally comes clean when Dorothy confronts him with his own failings. "I think you are a very bad man." she grumbles.
<end of page>

New paragraph on next page:
"Oh no, my dear," the Wizard concludes; "I'm really a very good man, but I'm a very bad Wizard, I"
<end of page>
must admit."
<end of page>

[tartanpion]

Originally Posted by DNSB

Looking at the "About Kobo Aura HD", it says the Reader Mobile software is copyright by Adobe 1995-2013. Complaints to Adobe might be more to the point than complaints to Kobo. Though if you think Kobo does not respond well to bug reports, try Adobe for sheer indifference.

Regards,
David

We can say that kobo is fully responsible because in mantano reader which also uses adobe reader mobile in a newer version this bug is solved for a long time.

[DNSB]

Originally Posted by ShellShock

And even if Adobe did fix this bug, how confident are we that a new release of Adobe reader mobile would not contain new bugs? Kobo probably cannot devote a lot of resources to a full regression test, so they probably prefer to direct effort to kepub support instead, i.e., where they control the software development.

Actually, Kobo does not control much of the software development for kepub support since they use the ACCESS NetFront BookReader software. I'd suspect that Kobo would have more influence with ACCESS but that's just a personal opinion with no visible means of support. ACCESS also uses quite a bit of open source which is downloadable if you want to go through the 93MB tarball for the BookReader software.

http://gl.access-company.com/news_ev...2012/120712-2/

Regards,
David

[Anak]

Originally Posted by DNSB

Looking at the "About Kobo Aura HD", it says the Reader Mobile software is copyright by Adobe 1995-2013. Complaints to Adobe might be more to the point than complaints to Kobo. Though if you think Kobo does not respond well to bug reports, try Adobe for sheer indifference.

Regards,
David

Originally Posted by DNSB

Actually, Kobo does not control much of the software development for kepub support since they use the ACCESS NetFront BookReader software. I'd suspect that Kobo would have more influence with ACCESS but that's just a personal opinion with no visible means of support. ACCESS also uses quite a bit of open source which is downloadable if you want to go through the 93MB tarball for the BookReader software.

http://gl.access-company.com/news_ev...2012/120712-2/

Regards,
David

You point out that there are bugs in the rendering engines (Adobe or Access) and not bugs caused by Kobo and therefore (also) should contact Adobe or Access about those bugs and they probably don't care.
But Kobo and any other company that uses these engines bring in much more "mass" to get the most important bugs fixed.
Hopefully this will improve with a full epub3 renderer. I don't know is Kobo planning to use the new Readium engine or adds epub3 support to the engines they currently use.
I don't know if Kobo (or other vendors) update their current line of devices with the most recent available versions of the engines.
But open source projects (like OpenInkpot) seems to be all dead.
I'll wait for an installable version of KOreader to check it out (and find some bugs too).

[DNSB]

Originally Posted by Anak

Hopefully this will improve with a full epub3 renderer. I don't know is Kobo planning to use the new Readium engine or adds epub3 support to the engines they currently use.
I don't know if Kobo (or other vendors) update their current line of devices with the most recent available versions of the engines.
But open source projects (like OpenInkpot) seems to be all dead.
I'll wait for an installable version of KOreader to check it out (and find some bugs too).

ACCESS and Kobo are both members of Readium and the ACCESS renderer is partly EPUB3 compliant and, from their website, is moving in the direction of full EPUB3 compliance.

The problem being is that Kobo still uses the Adobe engine for epub2 files. I suspect this is mostly for compatibility with Adobe's ADEPT DRM scheme which is used for most DRMed epub files. Adobe did have a roadmap for EPUB3 but that road map has disappeared.

As for the ARM engine update, that's hard to tell. The file dates seem to change but that could just be an artifact of the build process.

Regards,
David

[taming]

Originally Posted by DNSB

ACCESS and Kobo are both members of Readium and the ACCESS renderer is partly EPUB3 compliant and, from their website, is moving in the direction of full EPUB3 compliance.

I believe the ACCESS renderer is fully compliant, but not all of the features are implemented (yet). Might be picking nits there . From my perspective, this whole Readmium biz is fascinating and a major piece of the puzzle when we look at development and the future. Nice to see other folks following this.

[AlexBell]

Originally Posted by DNSB

Looking at the "About Kobo Aura HD", it says the Reader Mobile software is copyright by Adobe 1995-2013. Complaints to Adobe might be more to the point than complaints to Kobo. Though if you think Kobo does not respond well to bug reports, try Adobe for sheer indifference.

Regards,
David

For what it is worth the 'long paragraph' bug does not occur on my Sony readers, but does appear on my Kobo Touch reader - when reading the same ebook of course. So far as I know Kobo uses the same version of ADE reader as Sony.

Also, for what it is worth, text rendered as italic on all of the fonts on my Sonys is rendered as block on some fonts on my Kobo.

[jackie_w]

Originally Posted by AlexBell

So far as I know Kobo uses the same version of ADE reader as Sony.

However, none of my Sonys supports epub hyphenation but the Kobos do, so does this suggest Kobo are using a newer version of ADE? Or possibly it just means that Sony don't include any hyphenation dictionaries. I don't know...

[Ripplinger]

If this is the same bug I keep seeing constantly, it's not just long paragraphs. I've seen separate short paragraphs kicked to the next page for just 3 lines, then continue on to another page (and there's nothing in the css to cause this, no different style from the rest of the text such as a forced page break or a space after the last line).

I also see a lot of ending paragraphs in a chapter for only 3 lines that gets kicked to the next page, when the previous page has 3-4 lines left to fit it in easily. And again, there's nothing special in the code such as a forced blank line after the last line or anything different.

This happens frequently in every book, it's not a rare occurrence. And yes, it's very annoying and needs to be fixed.

[taming]

Originally Posted by Ripplinger

This happens frequently in every book, it's not a rare occurrence. And yes, it's very annoying and needs to be fixed.

I absolutely agree with you. That is why I convert to kepubs using the extended driver (which has a few bugs of its own right now). IMO, having poorly implemented epubs cripples the device.

[DNSB]

Originally Posted by Ripplinger

If this is the same bug I keep seeing constantly, it's not just long paragraphs. I've seen separate short paragraphs kicked to the next page for just 3 lines, then continue on to another page (and there's nothing in the css to cause this, no different style from the rest of the text such as a forced page break or a space after the last line).

I also see a lot of ending paragraphs in a chapter for only 3 lines that gets kicked to the next page, when the previous page has 3-4 lines left to fit it in easily. And again, there's nothing special in the code such as a forced blank line after the last line or anything different.

This happens frequently in every book, it's not a rare occurrence. And yes, it's very annoying and needs to be fixed.

You have to not only look at the css in the ebook itself but to understand that there are many css elements that have default values. In your case, it looks like you are running into widows: 3;, orphans: 3. This means that a paragraph that would leave 2 or fewer lines on at the top or bottom of a page will be forced to the next page leaving a blank space at the bottom of the previous page. Using Sigil or Calibre to add a widows: 0; and orphans: 0; to the stylesheet seems to cure most of those partial sentences.

The first issue you mention where there is an unexpected page break also seems to be font sensitive. Change the font you are using the read the ebook and (if you're lucky), the page display will look fine. I've never been certain but I think this is related to some of the other font handling oddities in the Kobo software leading to such issues as the very strict font naming convention both for sideloaded fonts and embedded fonts.

Regards,
David