https://bugs.documentfoundation.org/show_bug.cgi?id=165556
Bug ID: 165556
Summary: overlapping redlines: threat or menace?
Product: LibreOffice
Version: Inherited From OOo
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: enhancement
Priority: medium
Component: Writer
Assignee: [email protected]
Reporter: [email protected]
a question i'm pondering is if something should be done to prevent the
overlapping redlines from occurring; these can be created by writerfilter.
sw/source/core/doc/DocumentRedlineManager.cxx:112: redline table corrupted:
overlapping redlines
DocumentRedlineManager::AppendRedline() already ensures that Delete, Insert,
Format redlines don't overlap, these are all in maRedlineTable (Format may have
the same start/end as an Insert/Delete, but that can be handled easily).
then there are various Table* redlines but those are in a separate
maExtraRedlineTable.
additionally there are FmtColl and ParagraphFormat in maRedlineTable, those are
the ones that cause overlaps.
* FmtColl is always a point, but it could be contained inside Insert/Delete.
* ParagraphFormat is created as a PaM from start to end of a SwTextNode.
it looks like the main reason for it being a pam instead of a point is that the
SwRedlineItr can then apply the special redline format to the whole paragraph
... but actually that's something i just implemented in the fix for bug 165322
:)
... not sure if there's another reason? in Word it is only on the paragraph end
marker, not the whole paragraph, but Word will highlight the whole paragraph if
you click on it...
the FmtColl and ParagraphFormat could both be points and moved to a separate
vector maParagraphRedlineTable, eliminating all overlaps - then mainly
SwRedlineItr needs to search this and the GetContentAtPos() function ... but it
will also require code changes in unknown other places where currently
maRedlineTable is accessed.
the problem with overlapping redlines is that it prevents the binary search in
GetRedlinePos() and GetRedline() from finding the right place quickly; there is
a fall-back to linear scan in those functions, based on a flag if an
overlapping redline has ever been inserted.
now i have never looked at what Word/OOXML actually do with redlines, maybe
there's some other stuff there that isn't yet implemented but would require
overlapping redlines anyway?
--
You are receiving this mail because:
You are the assignee for the bug.
