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 <draw:text-box> 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