Issue 40572 - When bold text is selected and over-written, the format get lost
Summary: When bold text is selected and over-written, the format get lost
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: formatting (show other issues)
Version: OOo 1.1.4
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-13 12:37 UTC by rkollien
Modified: 2017-05-20 11:25 UTC (History)
1 user (show)

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


Attachments
This is a document, where the format loss can be reproduced (7.53 KB, application/vnd.sun.xml.writer)
2005-01-13 12:38 UTC, rkollien
no flags Details
Document to demonstrace that unformated white spacec before/after not always count (5.56 KB, application/vnd.sun.xml.writer)
2005-01-14 00:40 UTC, rkollien
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description rkollien 2005-01-13 12:37:15 UTC
In a document a text (f.e. a word or phrase) is formated as bold. When you 
select the word (double-clicking) and then over-type it, the bold format is 
gone. But - this doesn't happen to EVERY (bold) formated text. I don't know, 
why and when the format loss occurs.  
  
Don't blame me; i will attach (if this is possible) a document with this 
phenomenon. I than describe the necessary steps to reproduce the error.
Comment 1 rkollien 2005-01-13 12:38:54 UTC
Created attachment 21453 [details]
This is a document, where the format loss can be reproduced
Comment 2 rkollien 2005-01-13 12:43:16 UTC
Steps to reproduce the format loss error: 
 
- Open the attached writer document 
- Navigate down to the line containing the phrase "Herr Yyyyyy ThisName1" 
- Select one of the words (i do it by double-clicking. But seems to do not 
matter). 
- Type in some new text. You see, the format persists. 
- Now navigate down until you read: "( E-Mail-Adresse: ThisName2@medas.de )" 
- Select (by double-clicking) the word "ThisName2" 
- Again type in some new text. You see: the format is LOSS. 
 
Why the format persists in the first example but not on the second? I don't 
see any difference in the formating of the text? 
Comment 3 aggro 2005-01-13 20:19:57 UTC
I can verify this behaviour with Snapshot 1.9.69.

And I managed to find out why it works differently, here is why:
- The text "Herr Yyyyyy ThisName1" has white space between the words and the
style for those spaces is bold
- The space before the e-mail address is not bold.

Conclusion: If the word has character at the same line before it, the formatting
will be copied from there, not from the original text. If the word is at the
beginning of the line, it will keep the original formatting.

You can verify this yourself by changing the formatting for the white spaces on
the text.
Comment 4 rkollien 2005-01-14 00:40:00 UTC
Ok. So the cause of the behavior is defined. As selecting text by  
double-clicking on a word/phrase does NOT include leading or trailing (white)  
spaces, this can be confirmed to be a bug. It's abstruse for a normal user to  
keep in mind what format UNSELECTED white spaces have.  
  
BTW: I created a new document, typed some text, started format "bold", typed  
the word "bold", ended the bold format, typed a (unformated) white space  
followed by some text. When i now double-click on "bold" and overtype it,  
the bold format is kept! The white space before and after "bold" are definetly 
NOT formated. So this behavior isn't conformant with the explanation from 
aggro. I attach my mini doc (named "formathold.sxw"). 
 
Comment 5 rkollien 2005-01-14 00:40:53 UTC
Created attachment 21486 [details]
Document to demonstrace that unformated white spacec before/after not always count
Comment 6 michael.ruess 2005-01-14 09:23:57 UTC
MRU->OS: It is a bit inconsisten (or better: not really expected by trhe user)
that the format is lost when replacing the selected text in the described way.
It should be recognized by the application, that the selected text has a format,
which should be kept, though the preceeding character doesn't have.
Comment 7 Marcus 2017-05-20 11:24:46 UTC
Reset assigne to the default "issues@openoffice.apache.org".
Comment 8 Marcus 2017-05-20 11:25:48 UTC
Reset assigne to the default "issues@openoffice.apache.org".