View Full Version : Arbitrary breaks in long paragraphs


vampiregrave
11-27-2012, 06:06 PM
I've been struggling with a specific article with very long paragraphs. When i preview the epub file using calibre and ADE there's absolutely no problem, but when i test it in my Kobo Glo i find several arbitrary breaks, sometimes in the middle of the screen. As far as i can tell the problem resides in the lenght of the paragraphs. Is there any way to fix the behavior?

Terisa de morgan
11-27-2012, 06:25 PM
Try to set the attributes widows and orphans to 0 in css. It has worked for me.

vampiregrave
11-27-2012, 06:32 PM
Try to set the attributes widows and orphans to 0 in css. It has worked for me.

Already did. No effect unfortunately. Either it doesn't work or kobo's software forces some default value.

Terisa de morgan
11-27-2012, 06:46 PM
Sorry about it. I've modified .calibre in stylesheet.css to include them and it has worked.

vampiregrave
11-28-2012, 04:57 AM
Sorry about it. I've modified .calibre in stylesheet.css to include them and it has worked.

Thanks for the help anyway. I'm editing the stylesheet with SIGIL.
I noticed that reducing font size fixes most breaks (but makes it almost impossible to read comfortably).

Toxaris
11-28-2012, 06:52 AM
Perhaps the kobo ignores the orphans an widows settings.

Jellby
11-28-2012, 06:53 AM
That's probably related to the limited memory and processing power of reading devices (and Adobe-based software trying to make sure it works in smaller ones), and I don't think there's a way to properly fix it. You'd have to live with that and try to get the device and software developers to create better-behaved readers.

vampiregrave
11-28-2012, 07:50 AM
That's probably related to the limited memory and processing power of reading devices (and Adobe-based software trying to make sure it works in smaller ones), and I don't think there's a way to properly fix it. You'd have to live with that and try to get the device and software developers to create better-behaved readers.

Just noticed this issue is listed in the "Know Bugs in ADE" sticky. Guess i'm out of luck then. I'll probably post about this in the Kobo section.

Terisa de morgan
11-28-2012, 02:07 PM
Perhaps the kobo ignores the orphans an widows settings.

No, it doesn't, neither Mini nor Glo. I've tested at Mini and I girl at other forum has tested it at Glo. It works. She has done from the calibre GUI.

Arios
01-31-2013, 09:02 PM
Hello everyone,

Just a quick follow-up.

I was on the verge to create a new post, but I found this one. As it partially solves my "problem" I reactivated it today.

Indeed, the ePub I am trying to work with (Les chants de Maldoror, I. Ducasse aka Lautréamont), has some paragraphs up to 5 pages (8.5x11 doc file)! And I want it to be readable on my eReader.

First. The solution proposed by Terisa de morgan (widows and orphans to 0 in css) works! even with very long paragraphs. So many thanks to you Terisa because I was (desperately ;) ) seeking a solution and had really no clue.

This is curious because as Jellby, I believed that the problem was just a side effect to the limitations of eReaders on the market (lack of power, lack of memory: seem true for the Kobo Touch however).

Now, it works but not equally with the Kobo Touch and the Sony PRS-T1 I had on hand for testing.

With the Sony, the text wraps almost perfectly with all the long paragraphs, showing no memory or flow problems.

With the KT, things are not very good as several pages are cut erratically.

Trade off in both cases? Orphans and widows of course!

The text I'm talking about is certainly an exception, because the majority of authors do not create paragraphs nearly as long as chapters!

An interesting thing, perhaps, would be to test with other machines than the Sony and the Kobo Touch.

If you have any comments, it's would be appreciate.

davidfor
02-01-2013, 01:23 AM
The Kobo devices do have a bug with long paragraphs. Whether it is the Kobo specific or ADE, I don't know. But, as the Sony seems OK, it might just be Kobo.

What I see is that if the a paragraph has more text than a screen, the start of the paragraph will be moved to the top of the next screen. It was discussed in the Kobo forum late last year, but someone said it had been in all firmware versions. I played with it a little bit to see the limits, but I didn't try a paragraph as long as what you have, so I don't know what happens after several screens of text.

JSWolf
02-01-2013, 08:26 PM
It's not ADE. Long paragraphs work fine on my 650, Bluefire, ADE 1.7.7 & 2.0 for Windows.

It is yet another Kobo bug. I think Kobo needs to fire their programming staff and get new staff that can actually do the job.

vampiregrave
02-06-2013, 04:59 AM
The Kobo devices do have a bug with long paragraphs. Whether it is the Kobo specific or ADE, I don't know. But, as the Sony seems OK, it might just be Kobo.

What I see is that if the a paragraph has more text than a screen, the start of the paragraph will be moved to the top of the next screen. It was discussed in the Kobo forum late last year, but someone said it had been in all firmware versions. I played with it a little bit to see the limits, but I didn't try a paragraph as long as what you have, so I don't know what happens after several screens of text.

It's incredibly annoying and it seems to depend on font size; i tried the lowest sizes (pretty much ilegible) and it solved some of the random page breaks. Not exactly a fix though...

davidfor
02-06-2013, 05:49 AM
It's incredibly annoying and it seems to depend on font size; i tried the lowest sizes (pretty much ilegible) and it solved some of the random page breaks. Not exactly a fix though...

The font size does affect it. As I stated, a long paragraphs starts on the next screen if the paragraph would take more than a screen. This is more than a screen at the current font settings.

Arios
02-06-2013, 12:48 PM
First of all, thank you davidfor and JSWolf for your previous answers.

@ davidfor, I didn't know that bug in the Kobo: too bad especially if it's an old one!

@ JSWolf. I'm not far from sharing your opinion about the Kobo devs. But they continue to "try" and it's a good thing because the KT is not so bad.

@ vampiregrave. Regarding your long paragraphs: have you a lot of them? How long are they?

In my case (Les chants de Maldoror) long paragraphs are the norm. This is why it is not a good example. In fact, this is an exception.

Let try to think of solutions.

1. Break very long paragraphs, and only them. This "solution" is, however, contrary to the intention of the author. Not so good!

2. Create a division <div> for long paragraphs with the option "widows and orphans to 0 in css". I have not tested it yet, but that could just help the eReader.

3. Buy a Sony :D (just kidding).

If anyone has any other ideas it would be cool to share it.

Have a really nice day everyone!

JSWolf
02-07-2013, 11:58 AM
The reason the devs continue to try is because they are still trying to get it right. They would not have to try if they actually knew what they were doing. The Kobo hardware is not the problem. But the firmware leaves a lot to be desired and is rather buggy. I was tempted to get a Kobo Glo until I remembered about the firmware.

I just want a device that works. I don't want one I have to install firmware after firmware (and even unofficial firmware) in hopes that thing get fixed. It seems for everything that gets fixed, something else breaks. I am surprised anyone actually buys a Kobo.

When I found out about the embedded font bug that Kobo refuses to fix, I could not (in good conscience) recommend a Kobo to anyone and the bug is still not fixed and thus, I would suggest everyone stay the hell away from Kobo Readers.

As for #3. If you did buy a T2, it would work and long paragraphs would not be an issue.

Arios
02-09-2013, 03:59 PM
The KT is not perfect, far from it, but it works most of the time and the epub I was working with is really an exception.

JSWolf I own the PRS-T1 and as I have said (#10) long paragraphs do not pose any problems with it.

By the way in my opinion the PRS-T2 is a step backwards compared to the T1, which is why I bought the latter, and between the t2 and the Glo, I'd certainly choose the Glo ... despite the problems with firmwares which I admit are very annoying and hard to understand from a not so small company.

Anyway, my purpose was genuinely to find solutions regarding long paragraphs (how to deal with it in a strategic point of view!), not raised a comparison between Kobo and Sony!

Have a nice day JSWolf.

JSWolf
02-09-2013, 08:31 PM
The KT is not perfect, far from it, but it works most of the time and the epub I was working with is really an exception.

JSWolf I own the PRS-T1 and as I have said (#10) long paragraphs do not pose any problems with it.

By the way in my opinion the PRS-T2 is a step backwards compared to the T1, which is why I bought the latter, and between the t2 and the Glo, I'd certainly choose the Glo ... despite the problems with firmwares which I admit are very annoying and hard to understand from a not so small company.

Anyway, my purpose was genuinely to find solutions regarding long paragraphs (how to deal with it in a strategic point of view!), not raised a comparison between Kobo and Sony!

Have a nice day JSWolf.

It was not meant to be a comparison of Kobo and Sony. Sony was just an example. It could be Kobo and Onyx Boox or B&N or even Amazon. It was to say that other readers work where Kobo is buggy.

Arios
02-10-2013, 03:53 PM
Hi vampiregrave

If you are still reading this thread I found a "generic" solution and a more specific one that might suit you!

These was tested with the KT (firmware ver. 2.3.1).

1) The easiest thing to do.

Edit your epub with Sigil and add to the paragraph class <p> orphans: 0;
widows: 0. It should looks something like (...; = the specific codes of your own epub):

p {
...;
orphans: 0;
widows: 0;
}

Now here is the trick. Rename your file like this: name_of_my_epub.kepub.epub. Voilà! It works perfectly on the KT with my extravagant epub. The only drawback, of course, is that there are widows and orphans, but this is quite normal, is it not?

2) If you have few long paragraphs in your epub, you could instead just create a <div> in the CSS for them this way:

.lpara {
orphans: 0;
widows: 0;
}
and insert the div (<div class="lpara">) at the beginning of the long paragaph. Don't forget to put a </div> at the end of these paragraphs and to remove "orphans: 0; widows: 0;" from the normal paragraph.

But if the Glo works as the KT, you should be in business with the first solution.

JSWolf
02-10-2013, 06:55 PM
Even better...

Add the widows and orphans to the body style. That way you can turn them off for the entire ePub. It just looks better when most pages are the same number of lines.

Toxaris
02-11-2013, 03:55 AM
Actually I don't agree with you John. In real printing the lines are also not equal on each page. Widows and orphans have a real value with regards to the easiness of reading.

I find the solution of Arios with a special clause for long paragraphs actually quite elegant. I would not put it in a <div> though, but just say <p class="lpara">. In that case it would inherit everything from the <p> class, except for the things mentioned in the lpara class.

vampiregrave
02-11-2013, 04:49 AM
I'm still following the topic ;) I'll try your suggestions (beginning with the first; the eBook i'm working on has plenty of long paragraphs and it would take some time to indentify and test them all by adding a new class to them). Still, it is a shame that i have to create a different file specifically for Kobo users, in order to solve an issue that shouldn't happen in the first place.

Edit: And, of course, thanks for the help.

JSWolf
02-11-2013, 01:13 PM
Actually I don't agree with you John. In real printing the lines are also not equal on each page. Widows and orphans have a real value with regards to the easiness of reading.

I find the solution of Arios with a special clause for long paragraphs actually quite elegant. I would not put it in a <div> though, but just say <p class="lpara">. In that case it would inherit everything from the <p> class, except for the things mentioned in the lpara class.

There's just not enough screen real estate to waste with widows & orphans. Besides, I prefer no widows and orphans. I'm not bothered at all that it's not typographically correct.

In a pBook, things can be adjusted better so they don't look so noticeable. On a 6" eInk screen, widows and orphans are more noticeable and more annoying.

Jellby
02-11-2013, 01:30 PM
There's just not enough screen real estate to waste with widows & orphans. Besides, I prefer no widows and orphans. I'm not bothered at all that it's not typographically correct.

I just wanted to point (mainly for those that might read this) that you are against widows and orphans avoidance, i.e., you don't mind the occasional widow/orphan and you find the "cure" is worse than the issue.

vampiregrave
02-11-2013, 06:30 PM
Tried the first workaround and while it did solve the issue, it broke several classes (mainly alignment classes and embedded fonts).
I'm really wondering if it's worth all the trouble of creating a separate version, fix the formatting, just to prevent arbitrary breaks that happen only with Kobo's software...

Edit: Btw, adding the widow/orphan control to <body> or <p> doesn't work. Just tested it.

Arios
02-11-2013, 08:25 PM
You are welcome vampiregrave,

Toxaris, thanks for your kind words. If there is any benefits with the <div> your suggestion is the better one.

JSWolf I totally agree with you! I don't like widows and orphans as well and my epub is evidently readable with a computer or a tablet.

But either I must accept this tradeoff, either I chose to don't use it (as it is primarily) on my eReader. Personally, I can easily live with it and as I don't have any other solutions...

I also tested an epub named "maldoror.kepub.epub" with the Sony, and it works without a hitch.

By the way, I examined the epub with the KT and the TR-1 and there are not so much widows/orphans or wasted space; at least not enough to call mom at home.

Actually, here is where rely the most intriguing thing with long paragraphs for me: according to davidfor there is a bug with the Kobo and long paragraphs (see post #11), but this bug is not apparent, in my case at least, when using the .kepub extension and "widows and orphans to 0 in css". Very strange!

Do we have double standards here?

Anyway, it's fascinating to discover that such small devices can deal with the humoristic and satirical intentions of a eccentric author of the XIXth, even if this is "distorted" with some widows and orphans.

Update: Too bad vampiregrave! I have no embedded fonts in my epub, not even a font family as the eReader can use it's default one. As the "epub.kepub" works with the Sony and you have to change only few parameters in the CSS, you do not have necessarily to create separate version. Of course, it is up to you to see if the game is worth the candle. By the way, is your epub passes correctly epubcheck or FlightCrew for example?

vampiregrave
02-13-2013, 04:44 AM
By the way, is your epub passes correctly epubcheck or FlightCrew for example?

Yes. Basically i'm working on a project similar to Project Gutenberg, but dedicated to portuguese literature. After editing the text, i usually read the entire eBook in order to find any mistakes that i might have missed, and it also allows me to notice any bugs or formatting errors. Besides this annoying issue, everything else works just fine :smack:

davidfor
02-13-2013, 06:42 AM
I also tested an epub named "maldoror.kepub.epub" with the Sony, and it works without a hitch.

By the way, I examined the epub with the KT and the TR-1 and there are not so much widows/orphans or wasted space; at least not enough to call mom at home.

Actually, here is where rely the most intriguing thing with long paragraphs for me: according to davidfor there is a bug with the Kobo and long paragraphs (see post #11), but this bug is not apparent, in my case at least, when using the .kepub extension and "widows and orphans to 0 in css". Very strange!

Do we have double standards here?

Anyway, it's fascinating to discover that such small devices can deal with the humoristic and satirical intentions of a eccentric author of the XIXth, even if this is "distorted" with some widows and orphans.

Update: Too bad vampiregrave! I have no embedded fonts in my epub, not even a font family as the eReader can use it's default one. As the "epub.kepub" works with the Sony and you have to change only few parameters in the CSS, you do not have necessarily to create separate version. Of course, it is up to you to see if the game is worth the candle. By the way, is your epub passes correctly epubcheck or FlightCrew for example?

A "kepub" is a "Kobo ePub". It is the format that Kobo uses in their shop for direct download to their devices and apps. It is basically an ePub but with some extra formatting. The main thing you will notice is that it has spans around each sentence with a Kobo specific class and a sequential id. The ids are used on the device for bookmarking. There is also some javascript. Kobo also use a different DRM scheme that to the best of my knowledge hasn't been cracked.

The other important difference is that the Kobo devices use different renderers for epubs and kepubs. For epubs it is ADE, for kepubs it is Access or something like that. Kobo also support syncing the reading status and bookmarks for purchased kepubs to other Kobo devices and apps.

Changing the extension to ".kepub.epub" is a trick to get the devices to treat an epub as a kepub. It gets loaded on the device as an kepub and then is read with the kepub renderer. But nothing about it is synced to the server. Kobo do not officially support doing this and the only time I have seen them refer to it, they advised against it. Also, without the spans and ids, the bookmarks don't work. But, there are some scripts and a calibre driver that add the spans to a an epub to fix these problems./

As you found, there are differences between the two renderers. As ADE is used for epubs, it has the known errors. And that is why I questioned whether it is a Kobo specific bug or more general ADE issue. The kepub renderer uses WebKit. So, you get all the features and bugs of that. It also supports ePub 3, RTL languages and Japanese.

I'm curious about where you got "maldoror.kepub.epub". Kobo's kepubs usually have no extension and what looks like GUID for the name. I haven't seen them anywhere else.

Arios
02-13-2013, 10:08 PM
@ vampiergrave

I'm not familiar since a long time with epub, but in my own experience 2, perhaps 3 of them showed very long paragraphs.

Can I repeat my previous questions (post # 15)? Regarding to your long paragraphs: have you many of them? How long are they? How many epub with very long paragraphs do you have in your stable?

Just curious!

If you created yourself the long paragraphs, would it not be better to make them shorter? If you don't, we are in the same boat and the "possible" solutions seem to be here.

BTW, this is not really surprising that an unusual problem causes specific effects. Consequently Kobo in general and the Glo in particular are not the only culprits here: your very long paragraphs also play a role. Moreover, with widows and orphans set to 0 in the CSS and, for the KT with the kepub extension, things are nice for me. Finally, the Sony PRS-T1 doesn't work correctly without 0 for w/o either: there is a lot of wasted space without this setting. But as I said, the codes in my epub are really simple as well as my CSS, with no fonts embedded, etc.

@ davidfor

Thanks David for all these details about kepub.

I'm curious about where you got "maldoror.kepub.epub". Kobo's kepubs usually have no extension and what looks like GUID for the name. I haven't seen them anywhere else.

Ok, I was not clear. I just created it as an epub and renamed it as a kepub to see if it's going to work with the TR-1. In other words, this kepub is not coming from Kobo but from wikisource through me. Indeed, with the KT my "maldoror.kepub.epub" worked so well that I wanted to test it with the Sony. Of course, "she" was unable to take advantage to this "kobotisation"!

JSWolf
02-13-2013, 10:30 PM
Arios, can you please post a sample ePub with a long paragraph so I can try it on the T1 and see what I get? Thanks.

Arios
02-13-2013, 11:19 PM
Of course John: I was planning to put it here on mobileread... if I can solve the problem of long paragraphs :thumbsup:.

Your suggestions are welcome.

vampiregrave
02-14-2013, 04:53 AM
Can I repeat my previous questions (post # 15)? Regarding to your long paragraphs: have you many of them? How long are they? How many epub with very long paragraphs do you have in your stable?

Just curious!

At least 3-5 per chapter, more than 600 words or 3k characters. I'm working on a new title right now, and i noticed several long paragraphs in the first chapter (one has more than 800 words), so i'll probably use it as a test file later.


If you created yourself the long paragraphs, would it not be better to make them shorter? If you don't, we are in the same boat and the "possible" solutions seem to be here.

Working on public domain portuguese books, so i've got no choice.

Jellby
02-14-2013, 05:28 AM
There is a test file here which, among other things has some long paragraphs. I don't have a test with "widows: 0; orphans: 0", but that should be easy to add.

davidfor
02-14-2013, 09:19 PM
Ok, I was not clear. I just created it as an epub and renamed it as a kepub to see if it's going to work with the TR-1. In other words, this kepub is not coming from Kobo but from wikisource through me. Indeed, with the KT my "maldoror.kepub.epub" worked so well that I wanted to test it with the Sony. Of course, "she" was unable to take advantage to this "kobotisation"!

That explains it.

I put it on my Kobo Touch as an epub and a kepub. With the kepub renderer it looks very good. It looks good with the epub render except for all the extra paragraph breaks. I can't see a pattern for where the splits are occurring. And I am actually running beta firmware, so it doesn't look like it has been fixed for the next release.

By the way, I like the little bugs as separators. But, they look a little small on the Touch. The Glo has a higher resolution, so they would look smaller there. If it can be made a little bigger, it would be clearer what it was.

Arios
02-16-2013, 03:24 PM
It seems that everyone here was as busy as I was!

@davidfor

By the way, I like the little bugs as separators. But, they look a little small on the Touch.

David it was intended, because these bugs are like that in real life: in fact they are lice! And the illustration on the cover shows the same animal, "in all its splendor" :). Anyway, I'll try just to see with a bigger size.

BTW, I made other tests with the .kepub format and, unfortunately, this not as good or comprehensive as I expected: by renaming the epub, some of the initial formatting no longer work.

Bom dia and thanks vampiregrave for your reply.

Would it be possible for you to post a sample of an epub not working correctly?

Playing with it, we might be able to find a solution.

Jellby, your reader_test_epub is usefull. In it, the long paragraph is as long as some in my own epub (around 2200 words).

JSWolf I'm sure you found it, but just have a look to "CHANT TROISIÈME", the first and last paragraph.

vampiregrave
02-18-2013, 05:18 AM
Bom dia and thanks vampiregrave for your reply.

Would it be possible for you to post a sample of an epub not working correctly?

Playing with it, we might be able to find a solution.


Im working on a new one right now; currently finishing the second chapter, and it should have some examples. I'll probably test it on my Glo first. After that i can post it here; it's in Portuguese but it doesn't really matter in this case.

Arios
02-18-2013, 08:52 PM
Perfect!

My epub is in French a Portuguese one is nice.

Some long paragaphs and the CSS should suffice.

For my part, I consider the problem (long paragraphs) is solved, at least for now.

Hope to read you soon vampiregrave!

JSWolf
02-18-2013, 11:23 PM
JSWolf I'm sure you found it, but just have a look to "CHANT TROISIÈME", the first and last paragraph.

I noticed that page 70 (or 71) there is a paragraph issue. There is a wide empty space at the end of screen (using Reader Library for Windows). I do plan on trying it again with widows and orphans turned off.

Arios
02-19-2013, 12:06 AM
Curious!

I just had a look on the epub with Sigil and I found no empty space. Please, could you also try with Sigil and give me specific references (no page number but perhaps pieces of text I can search for?)

Did you try with ADE? Maybe the empty space is a result of widows and orphans set to 0.

JSWolf
02-19-2013, 11:03 PM
Curious!

I just had a look on the epub with Sigil and I found no empty space. Please, could you also try with Sigil and give me specific references (no page number but perhaps pieces of text I can search for?)

Did you try with ADE? Maybe the empty space is a result of widows and orphans set to 0.

I believe I solved the problem. Remove the page breaks from the CSS. It seems to work after that. There are 4 of them to be removed.

Arios
02-20-2013, 02:38 PM
page-break-before: avoid;

yes you can erase these codes.
It was for another test.

BTW with the KT and the Sony I didn't see negative or positive effects with them enabled.

PS. your new avatar is nicer than the old one ;)

JSWolf
02-20-2013, 09:27 PM
page-break-before: avoid;

yes you can erase these codes.
It was for another test.

BTW with the KT and the Sony I didn't see negative or positive effects with them enabled.

PS. your new avatar is nicer than the old one ;)

Thanks about the avatar.

Did you try removing the page breaks from the CSS?

Arios
02-20-2013, 10:38 PM
Yes I did, and actually there are not to be there.

But again, with the KT and the Sony all seem the same with or without.

JSWolf
02-20-2013, 10:45 PM
Yes I did, and actually there are not to be there.

But again, with the KT and the Sony all seem the same with or without.

(Jon are you a linux user? I have a dual boot with LMDE and it's a rock solid distro).

I used ADE on Windows 7 to view this.

vampiregrave
02-25-2013, 04:46 PM
Here's the file i promised. I noticed several breaks while testing:

Arios
03-01-2013, 08:58 PM
@vampiregrave, I like your epub and its classic look.

I did some tests on the KT (Kobo Touch) and the Sony, and of course, I met the same problems you faced.


With the Sony it goes a little better than the KT but the two failed before "Mais antigo na Espanha que o Condado Portucalense..." and "O Fidalgo encolhera os ombros..."

My suggestion (lpara) does not work, at least with your original file.

So I modified your epub. I removed the embedded font and added the codes you know about widows and orphans.

With the KT it goes better than before, but not perfectly (there are still gaps in the pages). But if, as I have already pointed out, we change the name to kepub.epub, it works as expected. So there is a known bug on the Kobo which affects epub files but not "kepub".

With the Sony the "revised" epub works correctly (no need to rename it!).

I guess the bug of the Kobo with long paragraph will eventually be corrected, so be patient. I wonder otherwise if it would be usefull to have a mechanism like : {paragraph-wrap: break-paragraph;}?

vampiregrave
03-04-2013, 06:56 AM
@vampiregrave, I like your epub and its classic look.

I did some tests on the KT (Kobo Touch) and the Sony, and of course, I met the same problems you faced.


With the Sony it goes a little better than the KT but the two failed before "Mais antigo na Espanha que o Condado Portucalense..." and "O Fidalgo encolhera os ombros..."

My suggestion (lpara) does not work, at least with your original file.

So I modified your epub. I removed the embedded font and added the codes you know about widows and orphans.

With the KT it goes better than before, but not perfectly (there are still gaps in the pages). But if, as I have already pointed out, we change the name to kepub.epub, it works as expected. So there is a known bug on the Kobo which affects epub files but not "kepub".

With the Sony the "revised" epub works correctly (no need to rename it!).

I guess the bug of the Kobo with long paragraph will eventually be corrected, so be patient. I wonder otherwise if it would be usefull to have a mechanism like : {paragraph-wrap: break-paragraph;}?

Interesting. So, besides the bug, the embedded font might cause some problems too...

Arios
03-04-2013, 01:28 PM
So, besides the bug, the embedded font might cause some problems too...

That seem to be the case, as far as my fast tests are good.

It is a pity because nobody here has tested the epub (yours and mine) with other ereaders than the Kobo & Sony, but we can assumed without too much risk that the Kobo is the culprit for now (btw with so many firmware updates, they are going to get rid of some old bugs one day :D).

As the problem is related to Kobo, I suggest you to look here (http://www.mobileread.com/forums/showthread.php?t=197843&highlight=readingOrphans%3D0&page=4 # 48 and ss) on a regular basis and you may request information to Mrs_Often and davidfor: they are both very nice persons and if they can, they'll help you I'm sure.

If you want my "version" of your epub for playing with, I can leave it here or send it to you via a PM.

vampiregrave
03-05-2013, 06:48 AM
It is a pity because nobody here has tested the epub (yours and mine) with other ereaders than the Kobo & Sony, but we can assumed without too much risk that the Kobo is the culprit for now ( btw with so many firmware updates, they are going to get rid of some old bugs one day :D).

I hope so...

If you want my "version" of your epub for playing with, I can leave it here or send it to you via a PM.

You can send it via pm and i'll check it out as soon as possible. Thanks for the help.

JSWolf
03-06-2013, 05:18 PM
That seem to be the case, as far as my fast tests are good.

It is a pity because nobody here has tested the epub (yours and mine) with other ereaders than the Kobo & Sony, but we can assumed without too much risk that the Kobo is the culprit for now (btw with so many firmware updates, they are going to get rid of some old bugs one day :D).

Until Kobo gets rid of the embedded font bug, I cannot recommend a Kobo reader to anyone. That's the bug that ignores font-family when it's in the Body CSS style. That means that a lot of eBooks with embedded fonts won't properly display the embedded font because the most common way to specify the main embedded font is via the Body CSS style.

But, as far as the other bugs, it seems that they fix some bugs and introduce new bugs with the firmware updates. I would find it too frustrating and either buy a different reader or go back to paper.

NedC
10-26-2013, 07:45 AM
Unfortunately widows:0 and orphans:0 are invalid css - values have to be >= 1. This doesn't appear to matter at the moment, but there's no telling which direction development will take.

And they don't always work - they seem to fix the problem on Sony readers, but on the Kobo mini long paragraphs are always littered with page breaks. Same goes for some Android apps I have tried, certainly Aldiko.

The problem appears to be caused by a combination of screen size and font size, neither of which are under the control of the designer.

davidfor
10-26-2013, 07:55 AM
Unfortunately widows:0 and orphans:0 are invalid css - values have to be >= 1. This doesn't appear to matter at the moment, but there's no telling which direction development will take.

Do you have a reference? using zero works perfectly on my Kobo devices.

And they don't always work - they seem to fix the problem on Sony readers, but on the Kobo mini long paragraphs are always littered with page breaks. Same goes for most Android apps I have tried, certainly Aldiko and Moon+

I don't believe that bug is related to widows and orphans. This hits when the paragraph is a bit longer than will fit on a screen.

The problem appears to be caused by a combination of screen size and font size, neither of which are under the control of the designer.

That is correct. It has nothing to do with the book (beyond the existence of long paragraphs) but is a bug in the reader code. From reports, it has happened on other ADE based readers, so it probably is a bug in the version that Kobo is using.

Jellby
10-26-2013, 08:51 AM
Do you have a reference? using zero works perfectly on my Kobo devices.

From the CSS spec (http://www.w3.org/TR/CSS2/page.html#break-inside): "Only positive values are allowed".

But what would you expect to accomplish with "0" that cannot be done with "1"? The value is the minimum number of lines in a page, if there are 0 lines, the pagebreak is between elements and not inside one, so these properties do not apply anyway.

I guess some readers will treat "0" or lower as "1", but maybe others will simply ignore values of "0" or lower.

davidfor
10-26-2013, 09:14 AM
From the CSS spec (http://www.w3.org/TR/CSS2/page.html#break-inside): "Only positive values are allowed".

Thanks.

But what would you expect to accomplish with "0" that cannot be done with "1"? The value is the minimum number of lines in a page, if there are 0 lines, the pagebreak is between elements and not inside one, so these properties do not apply anyway.

Good point. I don't know where I got the idea of "0". It might have been a post somewhere around here or experimenting.

I guess some readers will treat "0" or lower as "1", but maybe others will simply ignore values of "0" or lower.

The Kobo devices seem to treat "0" the same as "1".

DaleDe
10-26-2013, 12:42 PM
Thanks.

Good point. I don't know where I got the idea of "0". It might have been a post somewhere around here or experimenting.


The Kobo devices seem to treat "0" the same as "1".

Actually I have yet to hear of a device that does not honor 0 the same as one and widows and orphans really has nothing to do with splitting long paragraphs at arbitrary points unless it is related to only 2 lines being moved. By default ADE assumes a setting of 2 unless overridden in the CSS or styles setting. I think people that use 0 in widows and orphans mean off.

Dale