Simple floating environment?

[davidchisnall]

I'm currently using the figure and table things from resilient, but they appear as inline paragraphs. This causes two problems:

• Sometimes, there ends up being a page break in the middle of (or just before) the caption.
• Layout does not move paragraphs relative to each other and so the choice ends up being between a slightly overfull page (caption overlapping page number, for example) or a massively underfull one and the decision goes to the overfull one.

Good style requires that figures appear after the first reference to them. I can put each float in the source after the paragraph that contains the first reference, and I can manually move it down, but ideally the latter bit would be automated. The behaviour that I would like is to move paragraphs, but not other figures / tables / listings, up automatically to fill in the underfull page that is created if a floating thing needs to be moved to the next page. Is there a (moderately) simple way of doing this?

[davidchisnall]

After a false start looking at the page builder, I believe that I have an approach that can work for my use case and may be possible to generalise to other use cases.

I need to add two new properties on vboxes:

• Floating (can be moved)
• Float barrier (floats cannot be moved past this point).

When the page builder has found the optimal breaking point, try to set the glue. If this fails as under-full or over-full (currently reported to the user, but not the caller in setVerticalGlue), see if a fallback approach can work.

For an over-full page, is the last vbox floating? If so, try moving it one later in the queue and retry. Moving forward should collect other floating things (floats are not reordered with respect to each other), so you are actually searching for the next non-floating thing to move backwards. If the next non-floating thing is a float barrier, give up and use the best approach that you've found so far.

If a frame is under-full, try the same approach if the next thing that has not been typeset is floating (try to things from after it backwards to fill up the current frame).

This is nowhere near as good as implementing the dynamic programming model from the TeX papers (which I thought from @simoncozens talk, SILE already used for page breaking) but would give me something that would work, with the caveat that you can't have floats bigger than a page and floats can't contain footnotes (the latter is fixable, just work).

Does this sound plausible? Am I missing anything about how SILE works that would cause problems here?

[no-vici]

To make it possible to coexist, I think the right approach is:

• Modify the page-builder interface to make it non-mutating when calculating weights and then mutate as a second stage once the typesetter is happy with the result.
• Expose a hook in the typesetter that is given the page layout proposal (ideally with some badness metrics for a quick-accept pass) and can mutate the output queue and retry.

This would make it possible for my current code to be a very simple 'if the page is overfull or underfull, try moving some floats around' thing. As long as a parallel typesetter exposed the same hook, it could compose.

I'm studying your buildPage to see if anything applicable for parallel typesetting. I find it difficult to get my head around SILE's internals as there isn't a manual for them.

[no-vici]

The way it handles glue is wrong (unfortunately, I can’t tell the difference between glue associated with the moved object and glue associated with the previous / next paragraph), though visually it seems to work. It also doesn’t handle footnotes (I believe that should be possible to add, because I think they are associated with with another block). The more complex cases, such as footnotes spread across two pages, are much harder and I’m not sure how they should be handled.

Should we account for gTotal.stretch and gTotal.shrink in the GlueSize calculation?

function calculateGlueSize(pageNodeList, target)
    local totalHeight = SILE.types.length()
    local gTotal = { stretch = 0, shrink = 0 }
    local pastTop = false

    for _, node in ipairs(pageNodeList) do
        if not pastTop and not node.discardable and not node.explicit then
            pastTop = true
        end
        if pastTop then
            if not node.is_insertion then
                totalHeight:___add(node.height)
                totalHeight:___add(node.depth)
            end
            if node.is_vglue then
                gTotal.stretch = gTotal.stretch + (node.stretch or 0)
                gTotal.shrink = gTotal.shrink + (node.shrink or 0)
            end
        end
    end

    local adjustment = target - totalHeight
    local absAdjustment = math.abs(adjustment)
    local result = GlueResult.Valid

    if adjustment > 0 then
        if absAdjustment > gTotal.stretch and absAdjustment > SILE.settings:get("typesetter.underfulltolerance"):tonumber() then
            result = GlueResult.Underfull
        end
    elseif adjustment < 0 then
        if absAdjustment > gTotal.shrink and absAdjustment > SILE.settings:get("typesetter.overfulltolerance"):tonumber() then
            result = GlueResult.Overfull
        end
    end

    return adjustment:tonumber(), result
end

[davidchisnall]

My code there was copied from setVerticalGlue, trimmed to remove the things with side effects, and is expected to give the same result that setVerticalGlue would. I'm not sure what your change would do, is it copied from some other typesetter's equivalent logic (or something that's patched in the parallel package)?

[Omikhleia]

I don't have a strong opinion on the topic (and discussing code in a flow of comments is not straightforward), but looking briefly at the implementation,

• Using a "parbox" (from ptable.sile) is probably the wrong approach (it's an overkill, not fully satisfying)
• ... as well as checking a vbox line for a specially marked vbox parbox -- triggering something for all content that might be around the parbox in that same line... (arguably, the use case doesn't intend anything else in the line, but what the code does is wrong nonetheless)
• Moreover, currently "parbox" kills internal glue stretching (which might not be that wanted, notably in that case, esp. if we aim toward true baseline grid layout at some point).¹

Some of the ideas in the parbox code might be re-used or investigated as an example on how such a building block was made, but it's the wrong block for the intended purpose.

Footnotes

1. If I remember correctly the rationale: The current pagebuilder/typesetter logic accounts for stretchability on vglues, assuming (line) vboxes are fixed-height. This wouldn't necessarily be the case for such a "float" box, and needless to say, for a multicolumn block, and I do remember it as something I had to tackle in my earlier experiment at variable multicolumns (which is a generalization of the issues at stake, IMHO). ↩

[davidchisnall]

Using a "parbox" (from ptable.sile) is probably the wrong approach (it's an overkill, not fully satisfying)

Agreed. It was the quickest hack that worked to have something that grouped a bunch of things into a single element in the vbox queue. It's not the best approach, but it works as an initial prototype. An implementation that could be merged into SILE would probably want to explicitly group moveable blocks (e.g. figure+caption) but leave them unassembled.

... as well as checking a vbox line for a specially marked vbox parbox -- triggering something for all content that might be around the parbox in that same line... (arguably, the use case doesn't intend anything else in the line, but what the code does is wrong nonetheless)

Also agreed. All of mine are 100% width, so it works for the simple case, but a more advanced version would allow different-width floats and wither flow text around them or pack more than one on a line.

Moreover, currently "parbox" kills internal glue stretching (which might not be that wanted, notably in that case, esp. if we aim toward true baseline grid layout at some point).

This is actually a feature for my use case because it makes the distance between figures and captions is consistent. That are some ugly corner cases in LaTeX's float layouts as a result of not doing this. But, again, it's something that should be opted into selectively in a general solution.

The prototype works surprisingly well, but (as the comments attempt to describe) several of the things in it are hacks that could be improved.