<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi, yes needed to let attachment through.</div><div><br></div><div>Monotonically just means simple ie splitting will not leave space for a second split to succeed. </div><div><br></div><div>The example you presented is exactly that. The first row split leaves space for a second split to succeed. In the Table case because we have two kinds of split the seond is a row split. Your example was exactly that, but because of repeat rows the rsult looks wrong (ie 2 headers).</div><div><br></div><div>Logically if a row split succeeds and leaves a reasonable space then probably a further row split might succeed in the first rows of part 2. We aren't trying that now, probably because it's too difficult. Monotonic  behaviour would mean that an in row only would be the same as by row followed by in row on part 2, I'm not sure that's true.</div><div>--</div><div>Robin Becker</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 28 Nov 2025 at 18:01, Yoshua Wakeham <yosh@atticus.tech> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hey Robin,<div><br></div><div>Thanks for looking into this. You're probably right that the Table split code needs more thought! It's a difficult problem.</div><div><br></div><div>In your example, by-row split is preferred to in-row split, right? But if the "correct" solution is [0.1, 0.2.1] [0.2.2], then that is equivalent to preferring an in-row split to a by-row split. That is, if you prefer an in-row split, you would likewise end up with [0.1, 0.2.1] [0.2.2] (skipping the first by-row split altogether).</div><div><br></div><div>It seems to me that "preferring" a by-row split implies avoiding in-row splits that aren't strictly necessary. In general after we perform a by-row split between 0.1 and 0.2, we <i>know</i> there must not be enough space in the frame for 0.2, otherwise we wouldn't have needed to split in the first place. Therefore, if the next thing we try to do after splitting is try to fit 0.2 into the remaining space, the by-row split will always fail, and we'll always attempt an in-row split. Whether or not that succeeds will be exactly equivalent to the result of trying an in-row split of [0.1, 0.2] before trying the by-row split. Does that make sense? That's why I feel comfortable with the idea of letting 0.1 fill up the frame, at least if by-row split is preferred.</div><div><br></div><div>What does it mean for a flowable to split monotonically?</div><div><br></div><div>Thanks,</div><div>Yosh</div><div><br></div><div>P.S. I just noticed that our last few messages haven't ended up on the mailing list. Maybe a problem with the attachment size if the initial screenshots are still being attached?</div></div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>ld arise with any flowable that doesn't split monotonically.</div><div><br></div><div>I think the Table split code needs more thought.</div><div><br></div><div><br></div>ows). That ensures that the between-row split has the intended effect, and no content can "sneak" back onto the page. With my patch applied, the output looks like what we would expect:<div><br></div><br></div></blockquote></div></blockquote></div><div dir="ltr" class="gmail_signature">Robin Becker<br></div></div>
</div>