Bug 134321 - Inconsistent font direct formatting used when selecting and typing to replace/edit a word
Summary: Inconsistent font direct formatting used when selecting and typing to replace...
Status: RESOLVED DUPLICATE of bug 79364
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-26 15:00 UTC by tim
Modified: 2021-02-04 15:45 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tim 2020-06-26 15:00:26 UTC
Description:
When editing existing text, two common situations are:

  1. Select a whole word and type something to delete it and replace it with new text.

  2. Select the few first characters of a word and type to delete and replace with new text.

When the initial word to change has formatting different from the rest of the paragraph, I intuitively expect that the newly typed characters use the same formatting as the deleted piece. This is what happens in case 1., but not in case 2. for which the formatting of the text to the left of the cursor is used.

Could we have consistent behavior between cases 1. and 2.?

Steps to Reproduce:
1. Create a new Impress document.
2. Click on "Click to add Text" to place the cursor.
3. Type "aaa bbb ccc".
4. Select "bbb" (without including the spaces) and change the font color to red.
5. Select the first "b" and type "B" to capitalize the word.

Actual Results:
The replacement text "B" appears black.

Expected Results:
The replacement text "B" appears red.


Reproducible: Always


User Profile Reset: No



Additional Info:
If at step 5., you select the whole word "bbb" to replace it with "B", here the "B" appears red, which is I think the expected behaviour. For a word of length N>1, the problem happens only when selecting up to N-1 characters (starting from the first letter of the word).

Version: 6.4.4.2
Build ID: 1:6.4.4-1~bpo10+1
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: fr-FR (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 sora34ce 2020-08-04 18:25:40 UTC
I've been looking into this error and it's something that's been common in most text-based documents. Apparently alter the first character, it's altered to the default seen before it. If red is surrounded by black, the first red becomes black. I don't think it's an error, but we can see.
Comment 2 Buovjaga 2021-02-04 15:45:24 UTC
I reproduce already in 3.3.0. I found an older report, which was mistakenly closed: bug 79364

*** This bug has been marked as a duplicate of bug 79364 ***