Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Replacing first characters in a text portion sets a wrong formatting|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||ACCEPTED ---||QA Contact:|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
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).