[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