AMAZING!!

[RbnJrg]

I don't know where to post this but I just realized that ADE SUPPORTS widows and orphans and page-break-after: avoid. I did my test even with ADE 2.067532 and the properties WORK!

In order to enable widows and orphans I had to use the following statement:

p {
    widows: 2 !important;
    orphans: 2 !important;
}

After that I used:

p {
    widows: 1 !important;
    orphans: 1 !important;
}

and ADE -in both cases- respected the properties. Amazing! That means that ereaders based on RMSDK should also support widows, orphans and page-break-after: avoid.

[HarryT]

This is hardly news; ADE has always supported these properties . Happy to hear it's useful for you, though!

[roger64]

Hi Rubén

On Linux, I can't use ADE but of course, these are interesting news for ebook readers.

What I am also longing for would a reliable support for

page-break-inside:avoid

applied for example to a div.

[RbnJrg]

Originally Posted by HarryT

This is hardly news; ADE has always supported these properties . Happy to hear it's useful for you, though!

Well, I always had the belief that widows, orphans and page-break-after: avoid weren't supported by any ereaders. To me was a truly surprise to find that the buggy ADE supports those properties

[RbnJrg]

Originally Posted by roger64

Hi Rubén

On Linux, I can't use ADE but of course, these are interesting news for ebook readers.

What I am also longing for would a reliable support for

page-break-inside:avoid

applied for example to a div.

Can you post a text where that property should be applied? Now I think that ADE could have support for that.

[HarryT]

A pleasant surprise for you, in that case . ADE has supported these attributes for many years, though.

[DiapDealer]

Originally Posted by RbnJrg

Can you post a text where that property should be applied? Now I think that ADE could have support for that.

Now, page-break-inside: avoid IS problematic. Both in theory and in practice. What constitutes an unavoidable page-break-inside? You have to know that before you can even test. Whatever the case, I don't believe ADE tries very hard before it decides the page-break-inside was "unavoidable."

I think most people want to be able to use "page-break-inside: avoid" to keep captions and images together on the same page: i.e. wrap them in a div that has "page-break-inside: avoid" applied. "page-break-inside: almost-never" would be better, IMO.

[Hitch]

Originally Posted by DiapDealer

Now, page-break-inside: avoid IS problematic. Both in theory and in practice. What constitutes an unavoidable page-break-inside? You have to know that before you can even test. Whatever the case, I don't believe ADE tries very hard before it decides the page-break-inside was "unavoidable."

I think most people want to be able to use "page-break-inside: avoid" to keep captions and images together on the same page: i.e. wrap them in a div that has "page-break-inside: avoid" applied. "page-break-inside: almost-never" would be better, IMO.

Yes. This is the primary place. That, and, if you have a book with a crapload of subheadings, or subheads that go with charts, tables, etc., being able to slap 'em in a div and keep them all together would be NICE. I don't think it's earth-shattering, BUT, lemme tell ya, from the perspective of one who has to explain "that's the way eBooks work" about 3-5x every. single. day., I'd really be QUITE grateful to at least be able to page-break-inside: never for images or tables and captions, if naught else.

Hitch

[roger64]

I concur with all your comments.

Originally Posted by RbnJrg

Can you post a text where that property should be applied? Now I think that ADE could have support for that.

I will send you a MP. It's some floating images made out of two parts with text wrapped around. I put both parts of the image together within one div and gave it a class including this property.

I do not care if the full image is displayed on page A or page B but I do not wish to get the rider in page A and the horse in page B, so to speak.