Apache OpenOffice (AOO) Bugzilla – Issue 58012
Format or pasted text not respected for Copy Paste into text with text position 'subscript'
Last modified: 2017-05-20 11:15:15 UTC
When a text of several characters is selected and then directly overwritten by new text, one would expect that the new text gets the same formatting as the original text. This behaviour is also implemented in MS Word. In OOo the character formatting is not always preserved for the text. For example, if there is given the following text, where NNN means normal formatting and SSS subscript formatting: <paragraph>NNNNSSSSNNNNSSSSNNNN</paragraph> When NNNN in the middle is selected and overwritten by MMMM, then MMMM is formated normally. When NNNN at the beginning or end of the paragraph is selected, MMMM takes the subscript formatting. This is very strange and unexpected. Insted, the formatting of MMMM should always be normal. Some people on the german user-list reported, that also overwriting NNNN in the middle will result in subscript formatting.
Reassigned to SBA.
khbellgardt, any chance you could provide sample document?
Created attachment 39131 [details] To SBA: here is a sample file
I checked with "2.0.2 German version WIN XP: [680m5(Build9011)]" and also found some unexpected behaviour, but I still have to sort my results. A first test result you find in my attached document 'Overwritebug_wayofconstruction.odt'
Created attachment 39531 [details] unexpected behaviour for copy paste
I also saw the reported unexpected behaviour in 'Overwritebug.odt'. @khbellgardt: pls. specify your OS and Platform
To Rainer, sorry, I forgot. My actual platform is WinXpHome and OOo2.03.
SBA already was the correct owner of this issue...
SBA: I understand the behavior as follows: The selected "normal" string gets REMOVED before the first new character is entered. At this time, the newly inserted character "obeys" the formatting (subscript) at the cursor position. Thus the newly inserted characters are subscript, too. This sounds technically logical. The behavior of Word in this case is more intuitive. As long as the cursor keeps in that position, newly inserted charactes have the same attributes as the roved ones. So Word does remember the "attributes of the recently removed characters" as long as the cusor is not put in another position. Clicking somewhere else and back leads to the same bahavior of newly inserted characters (then being subscript, too). But in general, Writer can do, too: Other text attributes (i.e. "bold") behave as expected (caching the attributes when a selection is overwritten or "over-pasted", but not when it is deleted first (cursor staying in position) and then newly typed. SBA->FMA: This behavior should apply for all character attributes.
When NNNN at the beginning or end of the paragraph is easy to fix,that is,MMMM would be normal.
Created attachment 53576 [details] Please evaluate issue 58012
Thank you for your patch. I'll have a look as soon as possible.
fme->fl: Do we actually want to change our behavior in this case? fme->chenjunjun: Please submit your patch as 'unified diff', otherwise I cannot find out where exactly the patch has to be applied.
Created attachment 53656 [details] Thanks a lot
@fl: please, could you answer the question from fme?
@fl: ping!
Without an answer from Frank since a year I take the liberty to ignore him. The request makes sense for me and now we have to find out if the patch indeed implements it and if it is correct. So for now I raise the target. Michael, please take over.
hi chenjunjun, sorry for taking so long to look at your patch; i simply forgot about it. having had a look, i'm not sure your proposal is the right approach to fix this issue. your patch completely disables merging of text hints, which is not acceptable, because usually merging is a good idea; only in specific circumstances (like replace) should merging be disallowed. the underlying problem is that in the sw core model, the concept of a position at an attribute change cannot be expressed. for the sw core model, a position is always between 2 characters, and there may be several attribute changes between these characters. currently a replace operation is implemented by first deleting the original text, and then inserting the pasted/inserted text at the same text position. unless i am mistaken, in order to implement the desired behaviour, either this needs to be changed, or we need a higher fidelity position (and a flag to disable hint merging in this case).
retarget
I'm adding this comment to all open issues with Issue Type == PATCH. We have 220 such issues, many of them quite old. I apologize for that. We need your help in prioritizing which patches should be integrated into our next release, Apache OpenOffice 4.0. If you have submitted a patch and think it is applicable for AOO 4.0, please respond with a comment to let us know. On the other hand, if the patch is no longer relevant, please let us know that as well. If you have any general questions or want to discuss this further, please send a note to our dev mailing list: dev@openoffice.apache.org Thanks! -Rob
Reset assigne to the default "issues@openoffice.apache.org".