https://bugs.documentfoundation.org/show_bug.cgi?id=165556
László Németh <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected], | |[email protected] --- Comment #2 from László Németh <[email protected]> --- Michael (and Attila, see later), first of all many thanks for your improvements! (Also thanks to Noel for introducing the redline binary search and several other optimizations!) Indeed, the overlapping redlines were introduced by the writerfilter, likely as a trade-off between the available resources and the interoperability requirements, so there is no reason to keep this workaround, if there is a better solution: void DomainMapper_Impl::CheckRedline( uno::Reference< text::XTextRange > const& xRange ) { // Writer core "officially" does not like overlapping redlines, and its UNO interface is stupid enough // to not prevent that. However, in practice in fact everything appears to work fine (except for the debug warnings // about redline table corruption, which may possibly be harmless in reality). So leave this as it is, since this // is a better representation of how the changes happened. If this will ever become a problem, overlapping redlines // will need to be merged into one, just like doing the changes in the UI does, which will lose some information // (and so if that happens, it may be better to fix Writer). Handling format changes, and clearly separating them on the UI, like MSO does, may need overlapping redlines, at least in some restricted form: only a format redline can overlap a non-format redline. Handling format and text changes must be fully separated and not interfered, to reduce time and effort during managing changes, see the associated UX of Word (some information in https://support.microsoft.com/en-us/office/track-changes-in-word-197ba630-0f5f-4a8e-9a77-3712475e806a). It seems, non-overlapping, also overlapping redlines were not enough for MSO/DOCX, see moveFromRangeStart/End bookmarks for text moving, also table column/row moving (special changes, and it seems, it's possible to disable their recording in MSO: https://wordribbon.tips.net/T008834_Accepting_All_Formatting_Changes.html): https://c-rex.net/samples/ooxml/e1/part4/OOXML_P4_DOCX_moveFromRangeStart_topic_ID0EOYGW.html#topic_ID0EOYGW Moving sentences, and changing them has got a highly complicated user interface in Word, restoring full history of the changes, allowing accept/reject in all the phases. Adding loext:move-in by Attila, I like the recent user interface of Writer better: accepting the deletion part of the text movement accepts the insertion part(s) immediately. A newly introduced UX problem here, that accepting the insertion is not visible well. Also there is a much bigger UX problem: extra deletions inside the insertion part aren't tracked after the text moving (because the author and the time frame are the same). This is a huge and dangerous regression: the proofreader accepts other deletions without noticing them: Text: Lorem ipsum dolor sit amet Moving first two words + a space to the end: [Lorem ipsum ]dolor sit amet {Lorem ipsum } Inserting a space, removing "ip" and the terminating space: [Lorem ipsum ]dolor sit amet{ }{Lorem *sum*} Accepting the first deletion: dolor sit amet{ }Lorem sum So we removed "ip" (and the terminating space) silently, keeping only the space insertion. It's a good idea to fix the previous problem by always forcing the recording of the extra deletion from the same author in the same time frame during text moving. Also maybe a good idea to solve the known overlapping/format change problem in a similar way, like Attila did with the moved text (loext:format-in?), allowing to accept the same formatting change by a single click in Manage Changes: now a single character format change is split by every text change to three different redlines, which means three clicks in Manage Changes to accept all parts of the single format change. Also one of the clicks accepts the text change with the format change, and I'm not sure that correctly: it's not possible to separate them, as requested. Also Undo of the (format) change is still an interoperability problem, but maybe that doesn't affect overlapping. It would be possible to store the format change as the deletion and insertion of the same text, if needed, but the UX would be still a drawback. But maybe it's still better for interoperability, than creating DOCX from ODF for the victims of direct character formatting. -- You are receiving this mail because: You are the assignee for the bug.
