Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Inserted "special character" shown as "format change" by tracked changes|
|Status:||CLOSED FIXED||QA Contact:||issues@sw <issues>|
|Priority:||P3||CC:||cedric.bosdonnat.ooo, cno, issues, tenger|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description detroit 2010-03-19 02:45:20 UTC
In version 3.3.0 m74, whenever I insert a special character via the Insert > Special Character... menu, that change does not include the green-underline editing markup that I defined via the Changes option, but the character deletions do work OK in their markup.
Comment 1 eric.savary 2010-03-19 08:38:57 UTC
Please detail. Inserting a special character when Changes ("redlining") are ON does not display underlined as defined in Tools - Options - Writer - Changes but this ONLY when the character is inserted as first character in the document. What are your settings and detail if this happens anywhere else in the document.
Comment 2 michael.ruess 2010-03-19 08:57:14 UTC
Text inserted via "Special character" dialog is marked as "format change" by the tracked changes (aka Redlining) function. Broke in OOo 3.2.
Comment 3 cno 2010-03-19 09:00:30 UTC
would 3.2.1 be possible?
Comment 4 mst.ooo 2010-03-29 15:15:34 UTC
this is a regression from writerfilter32bugfixes01. SwTextShell::InsertSymbol works like this: 1. insert the special character: SwDoc::InsertString 2. set the font of the inserted character: SwDoc::InsertItemSet 3. reset the font behind inserted character: SwDoc::InsertItemSet these actions create following redlines and call SwDoc::AppendRedline: 1. an insert redline 2. a format redline: this one is deleted because there is an existing insert redline at the same start/end position (the one from 1.) 3. a format redline this one is deleted because it has no extent. so only the insert redline remains, and is visible to the user. in writerfilter32bugfixes01 the following line was commented out: docredln.cxx:1110: case POS_EQUAL: case POS_INSIDE: // TODO Check if there is any side effect //delete pNewRedl, pNewRedl = 0; break; with this change, the second redline is no longer deleted, but is inserted. this results in numerous assertions that the redline table is corrupted, and in the user-visible problem described in this issue. @cedricbosdo: what will break if the commented out line is activated again?
Comment 5 cedric.bosdonnat.ooo 2010-03-30 09:26:50 UTC
Created attachment 68631 [details] Document showing the problem that will appear when uncommenting the line
Comment 6 cedric.bosdonnat.ooo 2010-03-30 09:28:00 UTC
@mst: When uncommenting that line, the document I've just attached will not import the nested format change in the redlines (on the run "added ".)
Comment 7 mst.ooo 2010-04-01 15:31:41 UTC
@cedricbosdo: i see... there is one "format" redline more in the document, which is at the same position as the delete redline. hmm... ok, so we would lose some format redlines. afaik the msft formats support more redline options than writer can represent anyway, right? my concern is mainly with the assertions about a corrupted redline table that are raised with the format redlines that are now allowed with your change. afaik such assertions were written long ago by people who actually understood the sw redline implementation, its limitations and what can go wrong. i consider such an assertion firing rather scary. because unfortunately currently nobody understands the redline implementation sufficiently to determine what else may break in such a situation, i tend towards reverting this change. such a change should only be made with a thorough investigation of consequences. that would mean that such format redlines unfortunately cannot be imported for now, neither from ODF (not sure if they are allowed there), nor from other formats.
Comment 8 mst.ooo 2010-04-19 17:39:49 UTC
fixed in cws sw33bf03 http://hg.services.openoffice.org/hg/cws/sw33bf03/rev/0815d4653d9b
Comment 9 mst.ooo 2010-04-19 18:03:41 UTC
filed issue 110994 to track the regression in import filters that is introduced by the fix for this issue
Comment 10 eric.savary 2010-04-29 16:35:25 UTC
Reassigned to ES
Comment 11 eric.savary 2010-04-29 16:36:21 UTC
Verified in CWS sw33bf03