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

jhowell · 04-18-2020, 09:57 PM

Quote:

Originally Posted by iG0R

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

As a reader I would be very upset if font sizes were reduced automatically in order to avoid breaking up text. That would be a triumph of form over function.

iG0R · 04-18-2020, 10:03 PM

Quote:

Originally Posted by jhowell

As a reader I would be very upset if font sizes were reduced automatically in order to avoid breaking up text. That would be a triumph of form over function.

That is why code has to be written properly but not like it is now - just take a three-day HTML course to consider yourself a book compiler.
As I mentioned above "Processing block with break-inside:avoid (bear in mind this property almost always inserted consciously) depending on ..."
"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"

kovidgoyal · 04-18-2020, 10:04 PM

This endless arguing is pointless. NO BROWSER, chromium included, will ever resize content to honor break inside. Which means that by its very nature it is ADVISORY since there is never any guarantee that content will fit in the viewport. You as an author can attempt to do that by using viewport units for image sizes. Set your image height to 75vh for instance. Then assuming the viewport is large enough that 25vh provides enough space for the text they will not be split.

*All* that break inside guarantees is, that if the block is not at the top of the column/page and does not fit on the page it will be pushed to the next column/page. Chromium could well be buggy in implementing even that, but that changes nothing. If the block is too large to fit on even an empty page, IT WILL BE BROKEN UP. Therefore, THE PROPERTY IS ADVISORY.

And you really need to go argue with browser developers about this properties semantics.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Does page-break-inside:avoid work in azw3 files?	AlexBell	Workshop	4	04-21-2015 12:52 AM
Keeping text together (block vs. page-break-inside:avoid)	Psymon	ePub	2	10-12-2014 09:56 AM
page-break-after:avoid on iBooks	Oxford-eBooks	Apple Devices	1	08-12-2013 11:40 AM
Page-Break-Inside: Avoid - Solution or Hack?	sab1234	Kindle Formats	3	01-17-2013 04:10 PM
Page-break-inside:avoid and mobi	AlexBell	Kindle Formats	3	06-01-2011 06:03 AM

04-18-2020, 10:04 PM	#33
kovidgoyal creator of calibre Posts: 45,194 Karma: 27110894 Join Date: Oct 2006 Location: Mumbai, India Device: Various	This endless arguing is pointless. NO BROWSER, chromium included, will ever resize content to honor break inside. Which means that by its very nature it is ADVISORY since there is never any guarantee that content will fit in the viewport. You as an author can attempt to do that by using viewport units for image sizes. Set your image height to 75vh for instance. Then assuming the viewport is large enough that 25vh provides enough space for the text they will not be split. All that break inside guarantees is, that if the block is not at the top of the column/page and does not fit on the page it will be pushed to the next column/page. Chromium could well be buggy in implementing even that, but that changes nothing. If the block is too large to fit on even an empty page, IT WILL BE BROKEN UP. Therefore, THE PROPERTY IS ADVISORY. And you really need to go argue with browser developers about this properties semantics.

Advert