Re: Bringing multi-page floating tables to ODF

[Miklos Vajna <vmiklos@xxxxxxxxxxxxx>]

Hi Regina,

On Sun, Jul 16, 2023 at 07:31:22PM +0200, Regina Henschel <rb.henschel@xxxxxxxxxxx> 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.

> (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.

> (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". 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.

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)?

Thanks,

Miklos