Issue 110241 - Inserted "special character" shown as "format change" by tracked changes
Summary: Inserted "special character" shown as "format change" by tracked changes
Alias: None
Product: Writer
Classification: Application
Component: editing (show other issues)
Version: OOo 3.2
Hardware: Unknown Windows XP
: P3 Trivial (vote)
Target Milestone: ---
Assignee: eric.savary
QA Contact: issues@sw
: 111583 (view as issue list)
Depends on:
Reported: 2010-03-19 02:45 UTC by detroit
Modified: 2017-05-20 11:42 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Document showing the problem that will appear when uncommenting the line (10.35 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2010-03-30 09:26 UTC,
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
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 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:

                    case POS_EQUAL:
                    case POS_INSIDE:
                        // TODO Check if there is any side effect
                        //delete pNewRedl, pNewRedl = 0;

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.


what will break if the commented out line is activated again?
Comment 5 2010-03-30 09:26:50 UTC
Created attachment 68631 [details]
Document showing the problem that will appear when uncommenting the line
Comment 6 2010-03-30 09:28:00 UTC

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 2010-04-01 15:31:41 UTC

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 2010-04-19 17:39:49 UTC
fixed in cws sw33bf03
Comment 9 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
Comment 12 2010-05-14 13:58:57 UTC
*** Issue 111583 has been marked as a duplicate of this issue. ***