Bringing multi-page floating tables to ODF

[Regina Henschel]

Hi Miklos,

Miklos Vajna schrieb am 17.07.2023 um 08:51:
> Hi Regina,
> 
> On Sun, Jul 16, 2023 at 07:31:22PM +0200, Regina Henschel <rb.henschel at t-online.de> wrote:
>> (1) Should all types of <draw:frame> elements get this property?
>> <draw:frame> elements can not only contain a <draw:text-box> child element
>> but also a <draw:object> child element (e.g. Math, Chart) or a
>> <draw:object-ole> child element (OLE), <draw:image> child element,
>> <draw:plugin> child element (e.g. sound) or a <table:table> child element.
> 
> This is ineed interesting only for <draw:text-box>; I could move down
> the proposed attribute from <draw:frame> to <draw:text-box> if you would
> like that.

No, please do not move the attribute to <draw:text-box>. Such break is 
surely useful in case of a <table:table> child element too.

> 
>> (2) If this new attribute is intended to be used only for floating tables,
>> couldn't a <table:table> child element be used instead of the very generic
>> <draw:text-box> child element? That way it would be independent of any
>> special rules and handling for text frames and text boxes.
> 
> The tension is that on one hand, this is really about split frames, the
> content is not necessarily limited to just tables. On the other hand,
> I'm working on this feature mainly to be able to represent OOXML's
> floating tables in ODF, so it makes sense to limit the feature set to
> just table content.
> 
> I suggest that the ODF markup marks the frame/text-box as "allowed to be
> split", but I keep the UI on the libreoffice side limited to table
> content. I guess artifically limiting the ODF markup is not ideal.

I agree, for other content types it could be useful too, e.g. for 
<draw:object> and <draw:object-ole>.

> 
>> (3) In the proposal, a new attribute of the <draw:frame> element is used.
>> This means that the attribute belongs to the geometry of an individual
>> <draw:frame> element. An alternative could be to put this attribute to the
>> style of the frame. For example, the style:overflow-behavior attribute with
>> its values "clip" and "auto-create-new-frame" also belongs to the style of a
>> text box.
> 
> My thinking was that it's unlikely somebody would want this in a frame
> style, similar to e.g. "decorative".

Having it as attribute of <draw:frame> means, that you cannot make a 
document template that has this break enabled so that a user can enable 
"continue to next page" by simple applying a style. But not to be 
misunderstood, I am not against an attribute solution in principle.

  Also, if the attribute is moved
> down to <draw:text-box>, then that doesn't seem to have a
> draw:style-name attribute, so that would be always direct formatting.
> 
>> (4) The interaction with the fo:max-height frame-attribute, the
>> draw:auto-grow-height style-attribute and the style:overflow-behavior
>> style-attribute is missing.
> 
> - the intention is that these frames don't limit their height (you can
>    always create a next page and split), so fo:max-height is not meant to
>    be used if it's OK to split
> 
> - draw:auto-grow-height=false is not meant to be used if it's OK to
>    split, because the idea is to try to grow, then split if you can't
>    grow further
> 
> - style:overflow-behavior: oh, I was not aware of this attribute. This
>    is quite close to the one I propose, though the small (but important)
>    difference is that style:overflow-behavior would create a text frame
>    on the next page with the same position as the original; while a split
>    frame would start at the top of the next page, to minimize the amount
>    of frames necessary to present the text. Also, the dimension can be
>    different on a next page, e.g. 10cm height on current page, then
>    split, then 5cm height (minimum necessary) on the next page.

OK, that has to go into the description.

> 
> To sum up, I think there are some 3 options to improve the proposed
> markup:
> 
> 1) Move this to a frame style. This would still keep the confusing
> behavior for non-text-box frames.
> 
> 2) Move this to a text-box attribute (keep it as direct formatting).
> 
> 3) Use style:overflow-behavior=auto-create-new-frame instead of the
> proposed new attribute. This would lead to some problems regarding the
> position and size of the new frame. (The split frame is intentionally
> not created the way style:overflow-behavior=auto-create-new-frame wants
> it.)
> 
> Do you have any preference which improvement to pick? Are you OK to go
> with 2) and drop 1) & 3)?

For 3) the currently described behavior of that attribute is not usable 
and I don't like its restriction to text-box.
For 2) I don't like the restriction to text-box.

So I would go with a (A) style attribute or with (B) your original 
proposal as attribute of <draw:frame>. Restrictions to special kind of 
child elements could be done in the descriptions in both cases.

Michael, what do you think? From the point of view of workload for 
Miklos, it would of course be best to stick with the solution with an 
attribute of <draw:frame>.


I see an additional problem with this new feature:
The text which wraps around the table leaves a large gap on the first 
page, when the table increases so that it extends to the second page. I 
see, that Word has this strange behavior. I have only found [*]. The 
answer there is a workaround, only suitable in a final layout.
I'm afraid users will also complain to us that the text doesn't stay on 
the first page. I consider the layout in Word as bug in Word.

[*] 
https://answers.microsoft.com/en-us/msoffice/forum/all/text-wrapping-around-a-tabe-in-word/eb6fa861-7c3e-4765-9405-f247f03781d3

Kind regards,
Regina