<div dir="ltr">Dear Miklos,<div><br>Thank you very much for working on this issue! Tracked changes are an area that is still quite underdeveloped. As the feature is deeply integrated into the core, I understand maintenance must be quite complex.<br>On the last OASIS ODF TC, Regina asked me to provide a status quo of the change-tracking in ODF in general, as after a platform change former documentation is now harder to find.</div><div><br>In general, the progress of change-tracking in the ODF standard depends on the ODF implementations, such as LibreOffice.<br>Incremental improvements are valuable; at the same time, we should keep in mind that our design should ultimately be scalable enough to meet all current and foreseeable requirements. While we may not need real-time collaboration from the beginning, it would be great to ensure that the underlying data format can eventually support it. </div><div>At some point, we should be able to avoid transferring the entire document with each change, or group of changes. One of the challenges we face is that both ODF and OOXML currently embed changes within the document structure itself. Without a proper positioning mechanism, it’s not feasible to transmit changes independently of the full document.<br>To illustrate: suppose you have an ODF document in read-only mode on your server for review, and I wish to propose a small edit—say, correcting a typo—similar to a "pull request." In this scenario, it shouldn’t be necessary to assign an ID to every possible element. All these explicit IDs would unnecessarily increase the file size, and even then, we wouldn't be able to address modifications at the level of individual characters within text.<br>Of course, XPath cannot work here, as ODF XML is not available at runtime like the DOM in a browser, allowing cross-browser scripting. But perhaps we could consider referencing higher-level semantic entities? We might group XML into logical "puzzles" and reference elements by their position within these groupings. For example, in an ODT file, we could refer to the second character in the paragraph of an image or table using a notation like "/3/2" (or "2,1" if 0-based).<br>An encouraging aspect is that the semantic structures of ODF and OOXML are quite similar, which raises the possibility of defining a common approach across multiple—perhaps all—rich-text formats?<br>I have always imagined the future of change tracking as a means of serialising real-time collaboration, useful when the internet drops out, like when driving through a tunnel during a collaborative editing session in a train. In such a change model, we could store a list (or branch) of changes similar to commits, each based on patterns defined as XML changes within the ODF XML specification. This approach would substantially reduce complexity during live collaboration. For instance, inserting a table column could be treated as a single, labelled change pattern that encapsulates all atomic operations involved (adding a column at the right position and adding a cell in every row at the right position).<br>To bring this back to your present proposal: consider a simple text "ABC" where I apply a red style to "AB" and you apply bold to "BC"—a clear case of overlapping changes. Should we aim to support such scenarios already now, or would this be better addressed in a future, more robust design once we’ve moved past the current workarounds?<br><br></div><div>By the way, ODFDOM of the ODF Toolkit - being the back-end of some web-offices - already provides such a change implementation for text formats:<br><<a href="https://tdf.github.io/odftoolkit/odfdom/operations/operations.html">https://tdf.github.io/odftoolkit/odfdom/operations/operations.html</a>><br><br></div><div>Still, looking at the progress being made and from what I heard of core developers, this is anything but an easy task - likely nothing a company could bet its future on at this time. It could instead be a job for the foundation, but it might be difficult to tender, or hiring one or more developers to add this advanced cross-cutting feature, which is so fundamentally important for the future of LibreOffice.<br><br></div><div>Kind regards,<br>Svante</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 21 May 2025 at 15:58, Miklos Vajna <<a href="mailto:vmiklos@collabora.com" target="_blank">vmiklos@collabora.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Regina,<br>
<br>
I recently looked at the state of change tracking in Writer when 2<br>
tracked changes are on top of each other, see tdf#166319.<br>
<br>
The ODF side of this is strange: e.g. delete on insert was implemented<br>
in openoffice times, see<br>
sw/source/filter/xml/XMLRedlineImportHelper.cxx:206 and core.git commit<br>
52d244dee88b111631680d8cd4c8b922f9640c15 (- added: redline import,<br>
2001-01-10), at the same time some other combinations didn't work<br>
previously.<br>
<br>
Having researched this a bit, it seems Word supports 3 combinations and<br>
now I fixed the ODF filter to also handle these (see commits in the TDF<br>
bug). The old code had no tests, but now that I added tests for the<br>
newer combinations, I noticed that even the schema doesn't allow this<br>
markup, for something that OOo wrote since 2001.<br>
<br>
Anyhow, I attach my proposal to fix this, could you please file an OASIS<br>
issue for this?<br>
<br>
Thanks,<br>
<br>
Miklos<br>
</blockquote></div>