E-bokk viewer: Image+text+page-break-inside:avoid = issue

[iG0R]

kovidgoyal
I understand break-inside:avoid is an advisory property but it's so frustrating to read books with broken layout
Could you or someone advice how to edit Epub with minimum efforts, unlike Pop suggested, to fit image + text, which shouldn't be break apart, on one page while reading in E-book viewer?

[DNSB]

Originally Posted by iG0R

kovidgoyal
I understand break-inside:avoid is an advisory property but it's so frustrating to read books with broken layout
Could you or someone advice how to edit Epub with minimum efforts, unlike Pop suggested, to fit image + text, which shouldn't be break apart, on one page while reading in E-book viewer?

Unless you want to start reading PDFs, fixed layout epubs or similar, there is no "minimum effort" way to guarantee that a page break will not occur. Most ebook formats are reflowable which is the only way to have an ebook fit multiple screen resolutions and be readable (for those of us who consider flyspeck sized text to be unreadable).

[Quoth]

Originally Posted by iG0R

kovidgoyal
Could you or someone advice how to edit Epub with minimum efforts, unlike Pop suggested, to fit image + text, which shouldn't be break apart, on one page while reading in E-book viewer?

It's impossible without specification of a minimum size screen with a minimum resolution, eg. an 8" Forma can manage better than 9.7" Kindle DXG.

ebooks are best suited to text and images that can move or be resized, not textbooks with tables, graphs, photos and images.

The most common eink is 6" at 167 dpi for older ones and 300 dpi for new.
Almost all are mono, 16 shade. Some are only 4 shades.
Sizes vary from 4.3" to 13.8"

The smallest screen for ereading would be Palms at 160 x 160 and about 2.3", mono or colour, rare now. Some smart watches are a similar size but higher resolution
Most ebooks are read on phones, from 4.5" to 6.5", but the 5" to 6" is most common. It's a more elongated aspect than eink screens. Next up is tablets, 7" to 14", the 10" may be most common. They vary a lot in resolution.

A one solution fits all for your needs is not possible for the bulk of the ereader market. PDFs, fixed KFX and fixed epub3 allow it but alienate EVERYONE with eink or phones as they only work well on 10" or better tablets.

[iG0R]

Originally Posted by DNSB

Unless you want to start reading PDFs, fixed layout epubs or similar, there is no "minimum effort" way to guarantee that a page break will not occur. Most ebook formats are reflowable which is the only way to have an ebook fit multiple screen resolutions and be readable (for those of us who consider flyspeck sized text to be unreadable).

Then I do not understand why this property (page-break-inside:avoid) is advisory... Yes, most ebook formats are reflowable but it would be more logical if a viewer (Calibre E-book viewer or any other one) handled the layout of a book as an author insist how it should be and processed on its own if there is no special instructions.

[theducks]

Originally Posted by iG0R

Then I do not understand why this property (page-break-inside:avoid) is advisory... Yes, most ebook formats are reflowable but it would be more logical if a viewer (Calibre E-book viewer or any other one) handled the layout of a book as an author insist how it should be and processed on its own if there is no special instructions.

The spec writers decided that this was what THEY wanted for Web Pages.
EPUB is a subset of HTML.

Avoid is not the same as Prohibited (not a valid attribute for this case)

Advisory = attempt to comply. Not, Must comply (ADE 1.7 even ignore some of those. a 50% HR will not text-align:center. You need to do tricks)

[iG0R]

kovidgoyal
theducks

"page-break-inside: avoid" in Cromium is not an advisory property it's more like a buggy property.
Here is the bug report https://bugs.chromium.org/p/chromium...tail?id=547972

[iG0R]

Also:
https://www.chromestatus.com/feature/5630943616303104
https://bugs.chromium.org/p/chromium...tail?id=223068

Maybe it would be better to fix this issue in Calibre?

[kovidgoyal]

Originally Posted by iG0R

Maybe it would be better to fix this issue in Calibre?

By what magic?

[DNSB]

Originally Posted by iG0R

Also:
https://www.chromestatus.com/feature/5630943616303104
https://bugs.chromium.org/p/chromium...tail?id=223068

Maybe it would be better to fix this issue in Calibre?

Originally Posted by kovidgoyal

By what magic?

<serious mode off>
Kovid, are you trying to tell us that in your copious spare time you don't want to rewrite chromium?
<serious mode on>

[iG0R]

Originally Posted by kovidgoyal

By what magic?

Kovid "Gandalf" Goyal

Is it possible to integrate Calibre-Web's ePub handler into E-book viewer and Content server?

Originally Posted by DNSB

<serious mode off>
Kovid, are you trying to tell us that in your copious spare time you don't want to rewrite chromium?
<serious mode on>

[kovidgoyal]

There is no different engine. All rendering is handled by the browser engine. The browser engine can always decide to ignore break-inside if they feel like it. The only place this can be fixed is the browser engine. And it cannot in principle ever be fixed absolutely, since if the content in the block marked with break-inside is larger than the available space, it HAS to be broken up.

[iG0R]

Originally Posted by kovidgoyal

There is no different engine. All rendering is handled by the browser engine. The browser engine can always decide to ignore break-inside if they feel like it. The only place this can be fixed is the browser engine. And it cannot in principle ever be fixed absolutely, since if the content in the block marked with break-inside is larger than the available space, it HAS to be broken up.

Then I cannot get it how Calibre-Web and Calibre E-book viewer share the same browser engine but Calibre-Web faced with tall images in the block handles it properly to fit this whole block on one page even sometimes adding additional content (see screenshot) of the book on this page but Calibre E-book viewer breaks content consistency?
Definitely there have to be differences in how they handle content and therefore between their code. My main field of interest in IT is investigating bugs in software or hardware consequently I mainly use Assebmler in my hobby work but, IMHO, the algorithm of finding and fixing in the code still the same in both using Assembler and Python.

[moredrowsy]

Have you tried flow mode? It doesn't break up text into pages. If it doesn't work, then just live with reading the caption on the next page . Honestly, if the image is too long/tall, how do you logically think it's going to fix the text without space? Be reasonable man.

If there's no space, either shrink the image or it will break up the text caption into the next page. The SS with the issue shows a WAY SMALLER figure image than what you showed in the next SS with a large figure image. Makes no sense why you would compare that.

[kovidgoyal]

Pretty obviously whether something fits on a given page depends on the size of the page. The sizes of the pages are different in the two cases.

[iG0R]

Originally Posted by kovidgoyal

Pretty obviously whether something fits on a given page depends on the size of the page. The sizes of the pages are different in the two cases.

I always thought whether something fits on a given page depends on an algorithm implemented in the document's handler created by the IT specialist(s).
As mentioned above, several Chromium Project members confirmed "break-inside" is a buggy property, it has to work as it supposed to but doesn't and it is not advisory property (at least I didn’t find any reference to it as to an advisory property, all mentioned Chromium Project members consent that it has to avoid breaking but due to bugs in implementation it doesn't).
If in the code was strictly specified that it has to avoid breaking inside a block of content algorithm must process it so to prevent any disruption. How it should be handled - all depends on how sophisticated this algorithm is.
If the algorithm is rather simple it'll shift responsibility to the base handler of the browser at the same time more complex algorithm will try to process content by itself first of all using common sense and looking at CSS's properties. What common sense implies - the main goal is to comply to author's directives in the code and to give an opportunity to user to grasp the information in the content, i.e. ability to view image(s) and text:
Processing block with break-inside:avoid (bear in mind this property almost always inserted consciously) depending on what the block's content consists of:
1. only text
2. text+image(s)
3. only image(s)
->
1. only text:
- if it couldn't be fitted because the volume of text is too big but due to the author of the HTML code defined that this block has to avoid breaking -> Ok, whatever let's fit it on one page by resizing font since the author strictly defined "break-inside:avoid" property and it is unlikely this property was miscoded and even if it was author's failure it'll be visible at a glance and the author can fix it;
- if it could be fitted on one page -> Ok, let it be so.
2. text+image(s):
- if the image(s) is(are) too big to fit whole block on one page -> let's look at CSS ->
- img has height:auto property or there are no properties concerning its size -> resize image(s) to bare visible minimum size(e.g. min-height: 10%) -> if it couldn't be fitted even now -> Ok, whatever let's fit it on one page by in addtion resizing font size since author strictly defined "break-inside:avoid" property and it is unlikely this property was miscoded and even if it was author's failure it'll be visible at a glance and the author can fix it;
- img has strictly defined size (thus the author implied the img is more important then text) -> let's look at text's CSS, if it hasn't any limitations in font properties -> resize text to bare readable minimum size(e.g. 6px) -> if it couldn't be fitted even now -> Ok, whatever let's fit it on one page by resizing font since author strictly defined "break-inside:avoid" property and it is unlikely this property was miscoded and even if it was author's failure it'll be visible at a glance and the author can fix it;
- if the image(s) + text could be fitted on one page -> Do it, just do it!
3. only image(s):
- if the image(s) is(are) too big to fit whole block on one page -> Ok, whatever let's fit it on one page by resizing image(s) since author strictly defined "break-inside:avoid" property and it is unlikely this property was miscoded and even if it was author's failure it'll be visible at a glance and the author can fix it;
- if the image(s) could be fitted on one page -> Ok, accommodate it.