Re: Bringing multi-page floating tables to ODF

[Miklos Vajna]

Hi Regina,

On Tue, Nov 14, 2023 at 03:04:37PM +0100, Regina Henschel 
 wrote:
> I have now at least started. Sorry for the delay.
> https://issues.oasis-open.org/browse/OFFICE-4150
> 
> I hope I have got it so that it fits to your intentions. Better attribute
> names and wording can still be discussed.

Thanks a lot for creating the proposal. I think it captures the ideas
from this thread.

Regards,

Miklos

Re: Bringing multi-page floating tables to ODF

[Regina Henschel]

Hi Miklos,

I have now at least started. Sorry for the delay.
https://issues.oasis-open.org/browse/OFFICE-4150

I hope I have got it so that it fits to your intentions. Better 
attribute names and wording can still be discussed.


Kind regards,
Regina

Miklos Vajna schrieb am 12.10.2023 um 08:33:

Hi Regina,

On Wed, Oct 11, 2023 at 04:01:43PM +0200, Regina Henschel 
 wrote:

Thanks a lot. Please let me know when there is a proposal, I would like
to link to it from our extension schema.


Yes, of cause. However, the task has moved further down on my ToDo list,
because at the moment the things needed for the upcoming ODF 1.4 have
priority.


Makes sense.


Something else: do you have a preferred name for the XML attribute that
decides if the wrap should be only on the last page or on all pages?
Something like text:wrap-on-all-pages="", defaulting to false?


No, I have no preferred name. However, I would prefer a "style" prefix to
have it similar to the existing attribute "style:number-wrapped-paragraphs"
(20.326 ODF 1.3) and other wrap related attributes. So I suggest
"style:wrap-on-all-pages".


Fine, I don't yet have code for this, so any sensible namespace works
for me.

Thanks,

Miklos

Re: Bringing multi-page floating tables to ODF

[Miklos Vajna]

Hi Regina,

On Wed, Oct 11, 2023 at 04:01:43PM +0200, Regina Henschel 
 wrote:
> > Thanks a lot. Please let me know when there is a proposal, I would like
> > to link to it from our extension schema.
> 
> Yes, of cause. However, the task has moved further down on my ToDo list,
> because at the moment the things needed for the upcoming ODF 1.4 have
> priority.

Makes sense.

> > Something else: do you have a preferred name for the XML attribute that
> > decides if the wrap should be only on the last page or on all pages?
> > Something like text:wrap-on-all-pages="", defaulting to false?
> 
> No, I have no preferred name. However, I would prefer a "style" prefix to
> have it similar to the existing attribute "style:number-wrapped-paragraphs"
> (20.326 ODF 1.3) and other wrap related attributes. So I suggest
> "style:wrap-on-all-pages".

Fine, I don't yet have code for this, so any sensible namespace works
for me.

Thanks,

Miklos

Re: Bringing multi-page floating tables to ODF

[Regina Henschel]

Hi Miklos,

Miklos Vajna schrieb am 04.10.2023 um 10:04:

Hi Regina,

On Mon, Jul 31, 2023 at 06:09:31PM +0200, Regina Henschel 
 wrote:

I think it is all clear now. But I'll need some time to put it into a
proposal.


Thanks a lot. Please let me know when there is a proposal, I would like
to link to it from our extension schema.


Yes, of cause. However, the task has moved further down on my ToDo list, 
because at the moment the things needed for the upcoming ODF 1.4 have 
priority.




Something else: do you have a preferred name for the XML attribute that
decides if the wrap should be only on the last page or on all pages?
Something like text:wrap-on-all-pages="", defaulting to false?


No, I have no preferred name. However, I would prefer a "style" prefix 
to have it similar to the existing attribute 
"style:number-wrapped-paragraphs" (20.326 ODF 1.3) and other wrap 
related attributes. So I suggest "style:wrap-on-all-pages".


Kind regards,
Regina

Re: Bringing multi-page floating tables to ODF

[Miklos Vajna]

Hi Regina,

On Mon, Jul 31, 2023 at 06:09:31PM +0200, Regina Henschel 
 wrote:
> I think it is all clear now. But I'll need some time to put it into a
> proposal.

Thanks a lot. Please let me know when there is a proposal, I would like
to link to it from our extension schema.

Something else: do you have a preferred name for the XML attribute that
decides if the wrap should be only on the last page or on all pages?
Something like text:wrap-on-all-pages="", defaulting to false?

Regards,

Miklos

Re: Bringing multi-page floating tables to ODF

[Regina Henschel]

Hi Miklos,

Miklos Vajna schrieb am 31.07.2023 um 09:49:
[..]

Yes, I think that's a good compromise. Do you need anything else from me
to file an OASIS proposal for these 2 attributes?


I think it is all clear now. But I'll need some time to put it into a 
proposal.


Kind regards,
Regina

Re: Bringing multi-page floating tables to ODF

[Miklos Vajna]

Hi Regina,

[ Sorry for the slow reply, I was not reading mail last week. ]

On Wed, Jul 19, 2023 at 06:36:41PM +0200, Regina Henschel 
 wrote:
> > If you're interested in a setting similar to OOXML's
> > allowTextAfterFloatingTableBreak option, that would be rather
> > per-document, not per-table. And there is some benefit if ODF's matching
> > setting would be also per-document, it simplifies the job of ODF ->
> > OOXML filters. If that direction makes sense, then I guess this would be
> > rather a second boolean in settings.xml, not a 3rd value for the
> > proposed text:may-break-between-pages attribute.
> 
> I dislike to put such information which is essential for the layout of the
> document into the settings.xml. The settings.xml contains only
> implementation-dependent settings. I don't know whether other application
> even read it.

I agree it's not ideal that most of settings.xml is not standardized;
it would be indeed nice to standardize the "wrap on all pages" option.

> Perhaps we can make a compromise? Keep the text:may-break-between-pages as
> boolean attribute at the  element and add a second attribute to
> the style to describe how the text wraps around a  element,
> which spans several pages?
> 
> Thus way the "how-to-wrap" attribute can be stored in the top element of the
> styles hierarchy to have a document wide default which can be used for
> export to OOXML, but still be overwritten by the style of an individual
> frame for ODF.
> 
> I am an advocate of ODF and don't like limiting ODF to the capabilities of
> OOXML.

Yes, I think that's a good compromise. Do you need anything else from me
to file an OASIS proposal for these 2 attributes?

Thanks,

Miklos

Re: Bringing multi-page floating tables to ODF

[Regina Henschel]

Hi Miklos, hi Michael,

Miklos Vajna schrieb am 19.07.2023 um 16:15:

Hi Regina,

On Wed, Jul 19, 2023 at 02:40:26PM +0200, Regina Henschel 
 wrote:

Given that, I suggest to not use a boolean attribute in ODF, but use an
attribute with keyword values, so that all three ways can be represented.
This does not mean, that all three values need to be implemented in
LibreOffice immediately. But when there is some time later on, the missing
mode can be implemented without change to ODF.


That's certainly a possibility. I wonder if there is a use-case where
this wrapping mode would be different for different tables in the
document?


I don't know.



If you're interested in a setting similar to OOXML's
allowTextAfterFloatingTableBreak option, that would be rather
per-document, not per-table. And there is some benefit if ODF's matching
setting would be also per-document, it simplifies the job of ODF ->
OOXML filters. If that direction makes sense, then I guess this would be
rather a second boolean in settings.xml, not a 3rd value for the
proposed text:may-break-between-pages attribute.


I dislike to put such information which is essential for the layout of 
the document into the settings.xml. The settings.xml contains only 
implementation-dependent settings. I don't know whether other 
application even read it.


Perhaps we can make a compromise? Keep the text:may-break-between-pages 
as boolean attribute at the  element and add a second 
attribute to the style to describe how the text wraps around a 
 element, which spans several pages?


Thus way the "how-to-wrap" attribute can be stored in the top element of 
the styles hierarchy to have a document wide default which can be used 
for export to OOXML, but still be overwritten by the style of an 
individual frame for ODF.


I am an advocate of ODF and don't like limiting ODF to the capabilities 
of OOXML.


Kind regard,
Regina

Re: Bringing multi-page floating tables to ODF

[Michael Stahl]

On 18/07/2023 22:18, Regina Henschel wrote:

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 
 wrote:

(1) Should all types of  elements get this property?
 elements can not only contain a  child 
element

but also a  child element (e.g. Math, Chart) or a
 child element (OLE),  child element,
 child element (e.g. sound) or a  child 
element.


This is ineed interesting only for ; I could move down
the proposed attribute from  to  if you would
like that.


No, please do not move the attribute to . Such break is 
surely useful in case of a  child element too.


does any word processor use that though?

i'm assuming it's only used by Impress, where the 
"auto-create-new-frame" is far more appropriate, but i might be wrong.


So I would go with a (A) style attribute or with (B) your original 
proposal as attribute of . 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 .


i think either would be fine.

Re: Bringing multi-page floating tables to ODF

[Miklos Vajna]

Hi Regina,

On Wed, Jul 19, 2023 at 02:40:26PM +0200, Regina Henschel 
 wrote:
> Given that, I suggest to not use a boolean attribute in ODF, but use an
> attribute with keyword values, so that all three ways can be represented.
> This does not mean, that all three values need to be implemented in
> LibreOffice immediately. But when there is some time later on, the missing
> mode can be implemented without change to ODF.

That's certainly a possibility. I wonder if there is a use-case where
this wrapping mode would be different for different tables in the
document?

If you're interested in a setting similar to OOXML's
allowTextAfterFloatingTableBreak option, that would be rather
per-document, not per-table. And there is some benefit if ODF's matching
setting would be also per-document, it simplifies the job of ODF ->
OOXML filters. If that direction makes sense, then I guess this would be
rather a second boolean in settings.xml, not a 3rd value for the
proposed text:may-break-between-pages attribute.

Would that make sense? Just trying to avoid creating trouble for
ourselves. :-)

Thanks,

Miklos

Re: Bringing multi-page floating tables to ODF

[Regina Henschel]

Hi Miklos,

Miklos Vajna schrieb am 19.07.2023 um 08:26:

Hi Regina,

On Tue, Jul 18, 2023 at 10:18:53PM +0200, Regina Henschel 
 wrote:

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


Reading ,
there is an allowTextAfterFloatingTableBreak compat flag on the Word
side that would allow wrapping on all pages. At the moment Writer layout
assumes that this flag is off all the time. I don't see UI in Word to
enable this flag, but if I edit a DOCX file by hand, then it indeed
seems to do what you want.


Indeed, that works in Word.

Given that, I suggest to not use a boolean attribute in ODF, but use an 
attribute with keyword values, so that all three ways can be 
represented. This does not mean, that all three values need to be 
implemented in LibreOffice immediately. But when there is some time 
later on, the missing mode can be implemented without change to ODF.


Kind regards,
Regina

Re: Bringing multi-page floating tables to ODF

[Miklos Vajna]

Hi Regina,

On Tue, Jul 18, 2023 at 10:18:53PM +0200, Regina Henschel 
 wrote:
> 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

Reading ,
there is an allowTextAfterFloatingTableBreak compat flag on the Word
side that would allow wrapping on all pages. At the moment Writer layout
assumes that this flag is off all the time. I don't see UI in Word to
enable this flag, but if I edit a DOCX file by hand, then it indeed
seems to do what you want.

Given infinite time, I would like to have a matching Writer option in
tools -> options that allows doing the same, though short-term I'm more
interested in getting the current feature set more bug-free / stable.

Regards,

Miklos

Re: 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 
 wrote:

(1) Should all types of  elements get this property?
 elements can not only contain a  child element
but also a  child element (e.g. Math, Chart) or a
 child element (OLE),  child element,
 child element (e.g. sound) or a  child element.


This is ineed interesting only for ; I could move down
the proposed attribute from  to  if you would
like that.


No, please do not move the attribute to . Such break is 
surely useful in case of a  child element too.





(2) If this new attribute is intended to be used only for floating tables,
couldn't a  child element be used instead of the very generic
 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 
 and .





(3) In the proposal, a new attribute of the  element is used.
This means that the attribute belongs to the geometry of an individual
 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  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 , 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 . 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 .



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 

Re: Bringing multi-page floating tables to ODF

[Michael Stahl]

On 17/07/2023 08:51, Miklos Vajna wrote:

Hi Regina,

On Sun, Jul 16, 2023 at 07:31:22PM +0200, Regina Henschel 
 wrote:

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


i was not aware of this either; apparently LO is able to import this 
property since this year commit a925476352b3cb32f6384e7b0fb07e323bb6e64f 
but the interesting value "auto-create-new-frame" isn't implemented.


also it looks to me that "auto-create-new-frame" with these restrictions 
(same position and dimensions) only makes sense for Impress.


apparently this attribute exists in the ODF 1.0 schema, i wonder why it 
was added when it was never implemented in OOo/LO.

Re: Bringing multi-page floating tables to ODF

[Miklos Vajna]

Hi Regina,

On Sun, Jul 16, 2023 at 07:31:22PM +0200, Regina Henschel 
 wrote:
> (1) Should all types of  elements get this property?
>  elements can not only contain a  child element
> but also a  child element (e.g. Math, Chart) or a
>  child element (OLE),  child element,
>  child element (e.g. sound) or a  child element.

This is ineed interesting only for ; I could move down
the proposed attribute from  to  if you would
like that.

> (2) If this new attribute is intended to be used only for floating tables,
> couldn't a  child element be used instead of the very generic
>  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  element is used.
> This means that the attribute belongs to the geometry of an individual
>  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 , 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

Re: Bringing multi-page floating tables to ODF

[Regina Henschel]

Hi all,

after some more thinking and investigating:

I haven't found anything in the standard that limits the size of a frame 
to the page of its anchor. However, applications do this. So indeed 
something is required for the standard that specifies the limitation, 
which is actually done.


However, some questions still remain
(1) Should all types of  elements get this property? 
 elements can not only contain a  child 
element but also a  child element (e.g. Math, Chart) or a 
 child element (OLE),  child element, 
 child element (e.g. sound) or a  child element.
(2) If this new attribute is intended to be used only for floating 
tables, couldn't a  child element be used instead of the 
very generic  child element? That way it would be 
independent of any special rules and handling for text frames and text 
boxes.
(3) In the proposal, a new attribute of the  element is 
used. This means that the attribute belongs to the geometry of an 
individual  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.
(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.


Kind regards,
Regina

Re: Bringing multi-page floating tables to ODF

[Mike Kaganski]

I forgot to mention, that the feature that Miklos proposes can handle a 
situation when there's nothing on a given page, except for an 
intermediate part of this frame; in this case, a text box substituting 
this part of the frame would have no anchor opportunity, except for "to 
page", which would make the chain have not only different anchor points, 
but also different *anchor types*. It all would become only more 
complex, when additional factors and corner cases will be taken into 
account, in order to fit a "single contiguous object" concept into 
"chain of separate linked objects" existing feature.


--
Best regards,
Mike Kaganski

Re: Bringing multi-page floating tables to ODF

[Mike Kaganski]

Hi Regina!

On 12.07.2023 18:29, Regina Henschel wrote:

Miklos Vajna schrieb am 12.07.2023 um 15:46:

I attach a simple proposal to have a new optional boolean attribute, so
that it's possible to represent multi-page floating tables in ODF.

Could you please file an OASIS issue for me? I can't do that myself.

If there are any concerns, then I guess this list is the best place to
discuss that.


I think a new attribute in ODF is not needed. The desired layout of 
having a table in a text box which goes over several pages can already 
be written by using a chain of text boxes. Such chain is generated by 
the attribute draw:chain-next-name of the  elements.


Using a chain of text boxes has the advantage, that the solution exists 
since 1.1 and therefore is highly backward compatible and interoperable.


LibreOffice could detect the situation on import, that the chained text 
boxes contain only the parts of the same one table, and import it into 
an internal representation, that is designed for a good export to Word.


I'm afraid that a chain of text boxes is not a proper substitute for 
this feature.


A chain of linked text boxes is a fixed set of objects, each with own 
position; and own anchor (which is important), which is set in every 
place where this box should appear. These objects may have a common 
content (which flows from one of them to another), but the objects 
themselves are separate.


On the other hand, the feature that Miklos is talking about is a single 
entity, a frame that has only a single anchor, a single position/size 
definition, and which positions itself on as many pages as needed to fit 
its content, dynamically, where all the following parts of the frame on 
the next pages are not separate objects, but the same initial object.


This is similar to e.g. tables, or sections: you may have a *single* 
table, with arbitrarily large content; it will flow on to the next 
pages, but every next page's part of the table is not a separate table, 
but the same initial one. And it will re-arrange its layout on pages 
dynamically, when you resize pages, or add more content above. It will 
use its width and alignment when flowing to next pages.


Storing the chain of boxes would mean storing artificial objects in the 
document; their position would reflect not the *content* of the document 
(its semantics), but the actual layout on a specific system, that split 
the whole frame into specifically positioned pieces; this could be 
indeed different on a different system - say, where fonts are absent, 
which made substituted fonts to change the layout. The code would still 
need to disambiguate a proper chain of boxes (where user explicitly 
created such a chain, positioning the boxes arbitrarily) from the 
automatically layouted case, where these artifacts are actually one 
object - and that would also need introduction of a new attribute, which 
would defeat the intention to not extend the standard, but will fail to 
express the semantics of the new feature.


Hope this helps to avoid a confusion :)
Thank you!

--
Best regards,
Mike Kaganski

Re: Bringing multi-page floating tables to ODF

[Regina Henschel]

Hi Miklos,

Miklos Vajna schrieb am 12.07.2023 um 15:46:

Hi,

I attach a simple proposal to have a new optional boolean attribute, so
that it's possible to represent multi-page floating tables in ODF.

Could you please file an OASIS issue for me? I can't do that myself.

If there are any concerns, then I guess this list is the best place to
discuss that.


I think a new attribute in ODF is not needed. The desired layout of 
having a table in a text box which goes over several pages can already 
be written by using a chain of text boxes. Such chain is generated by 
the attribute draw:chain-next-name of the  elements.


Using a chain of text boxes has the advantage, that the solution exists 
since 1.1 and therefore is highly backward compatible and interoperable.


LibreOffice could detect the situation on import, that the chained text 
boxes contain only the parts of the same one table, and import it into 
an internal representation, that is designed for a good export to Word.


Kind regards,
Regina

Bringing multi-page floating tables to ODF

[Miklos Vajna]

Hi,

I attach a simple proposal to have a new optional boolean attribute, so
that it's possible to represent multi-page floating tables in ODF.

Could you please file an OASIS issue for me? I can't do that myself.

If there are any concerns, then I guess this list is the best place to
discuss that.

Thanks,

Miklos
= Summary =

Proposal owner: Miklos Vajna

Proposal short name: Frames may break between pages in for text documents

= Rationale =

Use cases:

A table inside a text document may be inside a frame, so that content can wrap
around it. A table can be also directly in the text document ("inline"), so it
can span over multiple pages if there is enough content in it. The proposal is
to allow the two use-cases at the same time: a frame containing a table and
also spanning over multiple pages.

Alternatives considered:

- Don't split tables in frames over multiple pages. This has the downside that
  it looks like some content is not in the document, while it's just not 
visible.

- Never put tables inside frames. This has the downside that content can't
  wrap around the table, even if there would be space for it. This can lead to
  more pages than necessary.

= Requested changes to the ODF Standard =

Text changes/additions (compared to ODF 1.3):

19.n text:may-break-between-pages (new section)

The text:may-break-between-pages attribute specifies if a frame may break
between pages in a text document or not.

The default value for this attribute is false.

The text:may-break-between-pages attribute is usable with the following
element: .

Schema changes/additions:

  

  

  

  

In other words, allow text:may-break-between-pages as a new attribute for 
.

= Impacts =

Conformance:

This proposal will not add any mandatory features or behaviors.

Backwards compatibility:

This change will not impact existing ODF processors, the usage of the new
element is optional.

Accessibility impact:

This change will not impact accessibility.

Interoperability:

OOXML's wordprocessingML has a  markup to describe a similar feature
(multi-page floating table), this proposal allows roundtripping that feature
in ODF. LibreOffice 7.6 implements this layout feature in its ODF extension
namespace.