Apache OpenOffice (AOO) Bugzilla – Issue 11450
WW8: Redline Fix 1st. Winword redlines *can* overlap, our cannot.
Last modified: 2017-05-20 11:19:51 UTC
As the attached example (see issue 6596 for source) shows winword a redline can appear to be deleted before it has been added. This can happen because the winword redlines are attributes and deletion is a seperate attribute to insertion. The scenario is this; Some text exists before any changes are made, it is then deletedby user A, and then *reentered* by user B. The affected range of text will be stored only *once* in the winword document. With both a deleted attribute and an added attribute attached to it. The deleted one has a datestamp previous to the appended one. This is something which doesn't work in writer. I imagine the solution is to duplicate in import the content where this occurs, either in the filter, or in the redlining core. Probably the filter :-(
Created attachment 4704 [details] overlap .doc
cmc->dvo: I add you as CC on this because you might be interested in why I think there are occasionally nonsensible overlapping redlines when importing .doc files. I'd be especially interested in any solutions you might think of around this type of "delete before insert" redline. If the filter has to check for overlaps of all previous redlines and *duplicate* content, similiar to how the redline code checks for overlaps and *splits* redlines then it will take forever to load a document :-(
dvo: ww is *weird*! Actually, I don't think this situation is too much of a problem, though. I see two issues: overlapping and chaining of redlines. Overlapping means that the actual redline ranges overlap. We don't do that. If redline overlap, they are being split up. I don't think this is a problem in this situation, though. The other is 'chaining' of redlines, e.g. if you insert something and someone else deletes this again. This will create a redline which chains an insert and a delete together. Something similar could be done for the ww redlines, except that the chaining order is different this time: insert after delete, instead of delete after insert. I don't think the current ::AppendRedline method lets you create this, but that should be a comparatively minor change. The bigger problem may be that this allows you to create real chains with more than two elements, and I'm not sure if everyone else (filters, UI, etc.) handle that. So, a WW file that looks like this: aaabbbcccdddeee 1. insert: ~~~~~~ 2. delete: ~~~~~~ would be processed as aaabbbcccdddeee 1. insert: ~~~ 2. ins+del: ~~~ 3. delete: ~~~ From an implementation point of view, you would do two AppendRedline calls, which would do the splitting up for you. (That's service, heh?) Since SwDoc::AppendRedline is on my urgently-needs-rewriting-for-2.0 list, one could keep this in mind and make the required changes while being at it. For the full solution, you'd still need to confer with UI+filter people. dvo->cmc: Sounds good?
That is exactly what I wanted to hear. I was indeed hoping to have the majority solution on the redline side and not have to duplicate loads of work in the winword filter.
reopen to reassign
cmc->mmaher: This demonstrates one of the core problems with redlines, please co-ordinate with dvo and so on as to whether this is done, or unfinished. Getting this example .doc here working is the first step to fixing the other redline import problems for the .doc format. I think we've reasonably outlined the problem here.
Because of a shortage of resources we cannot promise to fix this issue for Q.
mmaher->flr: Yours I think
assigned to hbrinkm
Reset assigne to the default "issues@openoffice.apache.org".