Float images & tables?

[jbacelar]

Originally Posted by Phssthpok

There are pages, certainly; that's what page-break-before and page-break-after are there to control in the CSS.

Certainly there are no pages (the fixed pages in a paper book), but screens, displays, or as we like to call them.

Originally Posted by Phssthpok

So don't you think it would be useful to be able to tell the viewer not only where hard page breaks should go but that a block should float to the top of the viewer's display page when it is displayed?

With page-break after and float, you already have this, but your initial problem still exists:

Originally Posted by Phssthpok

Is there a way to float a block element in a reflowable book (e.g. a table, or a div containing an image and caption) so that it will be displayed at the top (or bottom) of a page, and so that text will be flowed around it to avoid having a huge blank area on the page before?

[Hitch]

Originally Posted by jbacelar

Certainly there are no pages (the fixed pages in a paper book), but screens, displays, or as we like to call them.



With page-break after and float, you already have this, but your initial problem still exists:

The problem is--and, yeah, verily, I've looked into this: even if you COULD do this--where does it stop? Where does it stop flowing the text "around" the element that is now like a rock in the stream? Because if this worked, my thoughts lead me to an ePUB (or MOBI or..) that has a clump of images or tables, etc., at the end, as all the text that wasn't held up, has flowed around it, gone on ahead--so to speak.

The element becomes a logjam. Other images and tables couldn't flow past it. You'd end up with what would look like a too-long pair of jeans, all bunched round someone's ankles...all the images, tables, etc., stacked up against each other at the end (rocks) whilst the text (water) flowed around that first one, leaving all the rocks at the bottom/end.

Just saying.

Hitch

[JSWolf]

So you setup your table to have text floated around it and you like how it looks. But then try increasing the font size. Do you still like how it looks? Does it still work? Increase more and then again more. Can you go big and bigger and still have it work?

Because of the ability to use such large font sizes, it's best not to float a table even if you could.

[pdurrant]

Originally Posted by Hitch

The problem is--and, yeah, verily, I've looked into this: even if you COULD do this--where does it stop?

That's easy. It would stop at the beginning of the next page after the marker, when the image gets inserted at the top of the page.

At least, that's the cheap way to do it. TeX might also choose to put the image at the bottom of the page that would have contained the marker if the image wasn't at the bottom of it. that is, TeX can back-track its layout decisions to make a better layout.

But even just a 'put this element at the top of the next page' would be a splendid tool.

But there's so many things missing from ePub that would make book creators lives easier, and result in better looking books.

[Hitch]

Originally Posted by pdurrant

That's easy. It would stop at the beginning of the next page after the marker, when the image gets inserted at the top of the page.

Uhr? Paul, I mean, where does the flowing text stop? What's the indicator that the text should flow, to the prior page, and stop, in the body of the text, where? I'm not explaining this well, methinks. (Sorry, back injury, and I'm just NOT myself.)

At least, that's the cheap way to do it. TeX might also choose to put the image at the bottom of the page that would have contained the marker if the image wasn't at the bottom of it. that is, TeX can back-track its layout decisions to make a better layout.

But even just a 'put this element at the top of the next page' would be a splendid tool.

But there's so many things missing from ePub that would make book creators lives easier, and result in better looking books.

No, no, I mean--and maybe this is what you mean--what/where/how is the marker for the TEXT to stop flowing "through" the logjammed image? IOW, how do you say, okay, I have 4298 paragraphs in this book. I have (say), 20 tables/images. In the body of the text, near/around/close to, etc., the table...how do you say, flow this much text, but no more? If Jane Doe has the eyes of an Eagle, and has her font size at 1 (smallest), how much text flows past the logjammed element, before it STOPS flowing past it?

Hitch

[pdurrant]

Originally Posted by Hitch

If Jane Doe has the eyes of an Eagle, and has her font size at 1 (smallest), how much text flows past the logjammed element, before it STOPS flowing past it?

I'm not sure I understand the question, so I'll elaborate on how I see it working, and then perhaps I'll have answered the question.

The large item to be displayed (picture, diagram, table, etc) has an optimal position marked in the text.

The layout engine lays out text in pages until it gets to this item's optimal position marker. If there's room for the item on the current page when the layout engine gets to it, the layout engine lays out just enough additional text from past the item to make the item appear at the bottom of the current page.

Alternatively, there isn't enough space for the item on the current page. So the layout engine lays out enough text from past the item to fill that page, and then puts the item at the top of the next page.

In either case, the additional text that is moved from after the item to before the item is less than one page of text.

(TeX is clever enough to backtrack and undo text layout to fit the item at the top of the page on which its optimal position would have gone if that's 'better'. But we don't really need that.)

[DaleDe]

I believe Hitch's comment is about two images in a row or even x images in a row with only a small amount of text or none in between. Then when you try and delay the image you encounter, not more text, but another image. This can then stack up so that you have many images waiting to print until you have enough text to complete the page.

This is potentially an interesting issue but of course the user should be smart enough not to set up this kind of scenario since they have control over the CSS for each and every image. The latest CSS specification linked to in this thread has a different approach in that there is a block of data that has text and potentially one or more images. This approach limit the problem by only push the image around within the block. The user controls how much text and images in the block so thus control and disallows the stack of image to back up ad infintum.

Wolf thought that tables should be exempted since the size of the table is related to the font size. I think an algorithm can take this into account so long as the total block is the only area for the float table. The table can be made to start at the top of a page if it doesn't fit but, of course, after that it might overflow the new page if it is too big. I think this is an acceptable result. The idea starting it delayed to the top of the page is the best that can be done. If it gets too big it gets too big. The same can be true of a paper book that won't fit on one page.

I like the idea of permitting the object to be pushed both ways, to the bottom of the current page by shoving text later and the top of the next page by shoving text earlier. The CSS solution allows for this as well.

I think this could be a useful tool for conscientious eBook makers but it could be misused.

Dale

Dale

[Hitch]

Originally Posted by pdurrant

I'm not sure I understand the question, so I'll elaborate on how I see it working, and then perhaps I'll have answered the question.

Okey-dokey. Let's see what's what.

The large item to be displayed (picture, diagram, table, etc) has an optimal position marked in the text.

That part, I get.

The layout engine lays out text in pages until it gets to this item's optimal position marker. If there's room for the item on the current page when the layout engine gets to it, the layout engine lays out just enough additional text from past the item to make the item appear at the bottom of the current page.

OK. I think that this is why I'm saying potahtoe, and you are saying po-tay-to. I get the idea about the specific graphic element (image, table, whatev). No problem. I mean, conceptually. If there's enough room, it places the element, and text, until the page is filled. Basically, we can, more or less, do that now.

Alternatively, there isn't enough space for the item on the current page. So the layout engine lays out enough text from past the item to fill that page, and then puts the item at the top of the next page.

In either case, the additional text that is moved from after the item to before the item is less than one page of text.

Yes, BUT: let's say that you have two users. (I don't know if I can explain this very well, without drawing stuff, and I can't draw, so...). Jane reads at font size 1 (smallest). Joe reads at font size 8 (obviously, largest). How does the rendering engine know WHERE to stop flowing text, past this element? Is there a marker in the text, that says, essentially, "no matter what, never flow text for Element A past THIS point?" So that it's possible that the text might stop half-way through flowing past the element? Because you could have Jane reading on an iPad, and Joe on a smartphone, or vice-versa. If there's no "stop here" point, then where would the off-put element (the element that's now been delayed to page 2), ever land? Do you see what I mean?

Think of a river. You have water (text) and rocks in the stream (elements). Sometimes, the water is slow, sometimes fast, Different speeds, and thus, quantities, of water rush past the very same rocks. If the rendering engine is told to flow water at a higher rate of speed (amount of text) past the rock, because Jane is reading the book...and it pushed the element to the next page, what tells it to finally place the element on the next page? And more importantly, how to ensure that related text and element stay remotely together? IF you're discussing Figure 2, in the text, and it flows past the element to the top of page 1--or even further--and the graphic is now on page 3, you're accomplishing a "prettier" layout at the expense of usability, aren't you?

The other problem I see is, if text can rather endlessly flow past those rocks, wouldn't you end up with all the rocks at the back of the book, in a stack, with all the text having "gone first," essentially? Given what we have to work with? Y'know, maybe I'm just dumb, but I'm not sure I understand what type of algo you could write--given the limitations of what we do, I mean, basically HTML/CSS and a little sumpin'-sumpin JSON--to ensure that there's a stopping point (for flowing the text) past the rocks.

(TeX is clever enough to backtrack and undo text layout to fit the item at the top of the page on which its optimal position would have gone if that's 'better'. But we don't really need that.)

Wahllllll, maybe TeX is, but we all know, HTML and CSS ain't. Non? Sorry if I'm being thick.

Hitch

[DaleDe]

Originally Posted by Hitch

Okey-dokey. Let's see what's what.

Wahllllll, maybe TeX is, but we all know, HTML and CSS ain't. Non? Sorry if I'm being thick.

Hitch

Have you looked at the proposed CSS https://drafts.csswg.org/css-page-floats/?

Dale

[Hitch]

Originally Posted by DaleDe

Have you looked at the proposed CSS https://drafts.csswg.org/css-page-floats/?

Dale

Dale:

Not in detail, no. Skimmed? Yes. In detail? No. I admit I tend to put these things off until I know more than one device will be able to use whatever we're doing. Naughty, I know, I know.

Hitch

[pdurrant]

Originally Posted by Hitch

The other problem I see is, if text can rather endlessly flow past those rocks, wouldn't you end up with all the rocks at the back of the book, in a stack, with all the text having "gone first," essentially?

DaleDe raised a valid problem with image elements close together in the text ending up in a bunch.

I don't see your potential issue as a problem at all. An image will never appear later than the page following it's optimal marker place. (Except in DaleDe's scenario, where you might get several pages of consecutive images, immediately following the page ion which all their optimal markers have been laid out).

It sounds like the CSS committees are working on a sensible proposal. The real problem is that these will take years to make it into the official CSS, longer into ePub CSS, and even longer into common ePub rendering software. Sigh.

[pdurrant]

Originally Posted by Hitch

And more importantly, how to ensure that related text and element stay remotely together? IF you're discussing Figure 2, in the text, and it flows past the element to the top of page 1--or even further--and the graphic is now on page 3, you're accomplishing a "prettier" layout at the expense of usability, aren't you?

Perhaps considering a specific example will explain things better.

Let's have a text that contains a mention of Figure 1, and Figure 1 is (for one particular rendering page size) 1/3 of a page high.

In this layout, the mention of Fig.1 ends up half way down the page, and the paragraph it's in ends very shortly afterwards, and is followed by the Fig 1 optimal placement marker.

In this case, Fig.1 gets place on the page at its optimal position, and the text continues following it and onto the next page. No problem

Now consider what would happen at present if the paragraph it's in ends closer to the end of the rendered page than 1/3 from the bottom. There's no room for the image, so the bottom of the page is left blank - no Fig.1 until you move to the next page, when it appears at the top of the page, folowed by the text that comes after it.

With vertically floating images, the text from after Fig.1 would be laid out at the bottom of the page down to the end of the page, and then Fig.1 would again appear at the top of the very next page, followed by the remainder of the text that followed it originally.

Fig.1 ends up in exactly the same place as it would with current rendering engines. It's just that there isn't a nasty gap at the bottom of the preceding page.

In no circumstances would Fig.1 appear later than the very next page.

(Clearly, one of us is missing something. If it's me, please carry on - if I'm not understanding this, I'd like to know!)

[Hitch]

Originally Posted by pdurrant

Perhaps considering a specific example will explain things better.

Let's have a text that contains a mention of Figure 1, and Figure 1 is (for one particular rendering page size) 1/3 of a page high.

In this layout, the mention of Fig.1 ends up half way down the page, and the paragraph it's in ends very shortly afterwards, and is followed by the Fig 1 optimal placement marker.

In this case, Fig.1 gets place on the page at its optimal position, and the text continues following it and onto the next page. No problem

Now consider what would happen at present if the paragraph it's in ends closer to the end of the rendered page than 1/3 from the bottom. There's no room for the image, so the bottom of the page is left blank - no Fig.1 until you move to the next page, when it appears at the top of the page, folowed by the text that comes after it.

With vertically floating images, the text from after Fig.1 would be laid out at the bottom of the page down to the end of the page, and then Fig.1 would again appear at the top of the very next page, followed by the remainder of the text that followed it originally.

Fig.1 ends up in exactly the same place as it would with current rendering engines. It's just that there isn't a nasty gap at the bottom of the preceding page.

In no circumstances would Fig.1 appear later than the very next page.

(Clearly, one of us is missing something. If it's me, please carry on - if I'm not understanding this, I'd like to know!)

No. It's me. We're not communicating, and it's my failure. I don't feel so great today, but as soon as my brain is improved, I'll try to figure out a way to express what I'm trying to say.

;-)
Hitch

[Notjohn]

>the text from after Fig.1 would be laid out at the bottom of the page down to the end of the page, and then Fig.1 would again appear at the top of the very next page

Anyone who has read many e-books must be accustomed to those occasional short pages, just as he is accustomed to the occasional short line (much to be preferred IMHO to the wild hyphenating that is sometimes used to justify lines). I think that to begin a caption on a page without an image would confuse more people than it would help.

That said, I often try to work caption information into the preceding paragraph, to avoid situations where the image appears at the bottom of the page and the caption is forced to the next page. An image without caption information is more mysterious than caption information without an image, at least in the way I use images as illustrations for the text.

[pdurrant]

Originally Posted by Notjohn

Anyone who has read many e-books must be accustomed to those occasional short pages, just as he is accustomed to the occasional short line (much to be preferred IMHO to the wild hyphenating that is sometimes used to justify lines). I think that to begin a caption on a page without an image would confuse more people than it would help.

'Clearly', the coding would need to mark up the image and the caption as a unit (i.e. a div would enclose them) and it would be that div that would be moved around in the text.