Hi Guillaume,

you asked for ideas for your TODO in the description of this PullRequest (PR) draft, I have not fully figured out what are the TODOs, but I am happy to assist. :-)

From the PR's title, I see the consideration of nested paragraphs.
As some background, an office text document is in theory, just a sequence of paragraphs and tables. Tables being two-dimensional arrays are anomalies within the otherwise tree-ish graph structure of the text office document.
In general, the document is a tree, but there are cross-references within the document, therefore not a strict tree.
Long story short, by historic design, the ODF grammar does not foresee a nesting of this user feature, we call a paragraph. Nevertheless, you will find in the ODF Grammar nested text:p elements representing not only the paragraph feature but also encapsulating any visible text - like the text of annotations (shown aside of the text flow) are as well within text:p and descendants of a text:p.

Have a great week-end,
Svante

Hello,
Thank you for the background explanation. Indeed, in the case my issue describes, the problem comes from a paragraph in a draw:frame which is located in another paragraph.

Regarding the TODOs, they are in the code. Basically, in Selection#refresh, we need to know if a Selection is after an OdfContainerElement, knowing that the Selection is in a parent of the element. In TextNavigation#parentMatches, given a parent node and a child one, we need to get the (potential) next match in the parent text while avoiding re-matching the child node.
In both cases, for now, I simply extract the texts of both parent and child and checks the index of the child in the parent. If the index is not unique, I throw an exception (this is where I added TODOs, because I'm not really sure how to proceed in this case). If the index is unique, I can work with that.

Have a nice day,
Guillaume

@gtache Hello Guillaume,

when I did a few years ago the work on browser collaboration for Open-XChange to edit ODT documents in a web browser (our current main branch & 0.10.0 release), every ODF <text:span> became a TextSpanSelection. The totally new aspect added by the classes in the changes package was that there was an abstraction from the XML details to higher-level objects (we called components) that were already known to the user (e.g. table, image, character, paragraph, etc.).

In other words, instead of exchanging ODT as documents (full state), only the new user changes are being exchanged.
Therefore a full document (ODT) was being transmitted as a list of document user changes (as JSON).

I have not used the classes in the incubator packages (once added by IBM), but I think you are right it is good to fix that problem and even better to consolidate our sources.

Sorry, projects and corona-background-noises distracted me from pursuing your pull requests earlier, if you like to continue, I am open now for discussions - better late than never! :-)

Hope you are having a great weekend, Guillaume!
Svante