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.hensc...@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
