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
