Issue 24049

Summary: Replacing first characters in a text portion sets a wrong formatting
Product: Writer Reporter: akrioukov <basileia>
Component: codeAssignee: AOO issues mailing list <issues>
Status: ACCEPTED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: issues
Version: OOo 1.1   
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

Description akrioukov 2004-01-02 21:43:09 UTC
When I replace some character(s) with other characters at the beginning of a
text portion (i. e. text on the left side of the characters which should be
replaced has different formatting), the replacement gets the formatting of the
text from the left side, instead of retaining initial formatting of the replaced
characters. However, when the *whole* portion is replaced (i. e. text both on
the left and right side has different formatting), the replacement gets the
initial formatting of the replaced text (which is correct to my mind).

To reproduce:

1. Create a blank text document and input some words of text (e. g. "Some text").

2. Apply different formatting to a word (not the first word in the sentence).
For example, let's format "text" in Italic.

3. Select the whole portion of text you have just formatted ("text" in our case)
and input any character from your keyboard. Selection is replaced, but the
character you have typed is formatted in Italic. Everything is correct.

4. Now undo the last change, and select only the first character (or several
characters) in the portion which has different formatting (e. g. only the letter
"t" from the word "text". Input any character from your keyboard. Again, the
selection is replaced, but the character you have typed is formatted in plain!

I suppose this is a bug, because in all word processors I have tried replacing a
selection always applies to the replacement the initial formatting of the
selected text. Well, of course there is no problem to change formatting when you
replace selection from the GUI. The real problem is, that API functions (i. e.
XTextRange:setString and XSimpleText:insertString) produce the same effect when
applied at the beginning of a text fragment with specific formatting.

This makes writing any programs which should operate with text ranges in Writer
an extremely difficult task. Really, if I want to replace string for some text
range without losing its initial formatting, I have either to explicitly restore
this formatting (which is not so easy, and may cause some problems, see the
issue 23552) or use some tricks, like inserting new string at the and of the
range before deleting its initial content.

I'm unsure to which subcomponent this issue should belong (writer or api), but,
anyway, it looks very annoying.
Comment 1 rblackeagle 2004-01-03 19:43:48 UTC
I don't know if this makes working with OOo "Extremely difficult" but it is an
irritating feature and, unfortunately, one that I have just "worked with" even
though I did not like it, rather than filing an issue about.  Sorry.  It needs
fixing.
Comment 2 h.ilter 2004-01-06 11:54:05 UTC
Reassigned to FME
Comment 3 frank.meies 2004-01-13 11:16:45 UTC
.
Comment 4 zhang_yibo 2006-01-18 02:04:33 UTC
Successfully replicated the bug in OOo 1.1 running Linux 7.3, Intel Pentium 4
CPU 3.00GHz. I ran the instructions on the attached document and arrived at the
same result.

Further testing showed that formatting such as making the text bold, italics,
underlined, red (colour change), highlighted, a different font and a different
font size all produced the same problem. These problems also appeared when I
tested OOo 2.0.
Comment 5 zhang_yibo 2006-01-23 16:43:26 UTC
*Correction*

I did not run “the instructions on the attached document and arrived at the same
result.â€

Sorry for the inconvenience caused.
Comment 6 michael.ruess 2008-07-10 08:53:25 UTC
*** Issue 91526 has been marked as a duplicate of this issue. ***
Comment 7 pengo_au 2008-07-10 15:43:10 UTC
This has obviously been a problem since the beginning, and it's sad that it
still has not been addressed four-and-a-half years after this usability bug is
marked as first being filed.

See above duplicate (91526) for some demos of this bug (test cases).