Calc fails to retain format of a selected character in a way that contradicts every other program I've ever used, including Excel.
Steps to Reproduce:
1. in Excel, enter a cell
2. set the font color to Red
3. type R - a red R appears - type space
4. set the font color to Green
5. type G - a green G appears - type space
6. set the font color to Blue
7. type B - a blue B appears now you have R G B, each letter with its own color
8. with the mouse select only the green G
9. type g - a green g replaces the green G - this is desirable behavior - the user will often want to change a value without changing its format
10. repeat with Calc - a red g replaces the green G - it's same with superscript, bold and all other formatting options
When selecting and replacing a character, Calc, instead of retaining the format, looks backwards to the previous character (within the same cell) and forces that formatting on the user.
Calc should behave like Excel unless Excel has a bug or bad design. It should also behave like almost every other program on the market. Even after understanding Calc's behavior, it still take more keystrokes and mouse clicks to perform the same operation.
User Profile Reset: No
I wish you could stand behind a user and watch him or her spend hours working on formatting a massive spreadsheet with lots of border, backgrounds, format and font changes - and especially changes to individual characters within the same cell. You would see just how incredibly frustrating the program is. As always, I realize I'm complaining about a product that's free, and I still find it significantly less frustrating than Excel on balance, but Calc is not anywhere near as intuitive and intelligent as I would expect from such an ambitious un-corporate product. Excel is already there as a model. I would expect that you would take what works well in Excel and fix what doesn't, rather than leaving out superior Excel behavior for which millions of users have already transversed the learning curve.
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36
Created attachment 133324 [details]
demonstrates both sets of steps
This behavior is the same in all LibO applications. Therefore I set component to LibreOffice, hardware to all and version to inherited from OOo because LibO 3.3.0 shows the same.
Tested with 18.104.22.168 and 3.3.0.
LibO uses the formatting of the space before the inserted character. I couldn't reproduce it without spaces.
Add keyword needsUXEval, maybe it's an intended behavior. But I also stumbled over this issue in Writer in the past.
I think it is a bug, because it leaves over an empty span element. If it was an intended behavior, the empty span element would have been removed.
Created attachment 133373 [details]
I don't get the issue, see my screencast.
In general, we keep the style from the previous part for good reasons. Lets say want you enter a statement in bold, then you switch bold on first and enter the text later. If you do the same afterwards with a selection it makes of course no sense to keep bold active. The same is true for other style elements such as font color. Is that really different from other tools?
Your screencast does not contain the critical part. Mark the green G and enter a g.
Expected: You get a green g.
Currently: You get a red g.
Another hint (besides the empty <text:span> element), that this is really a bug: Do the same with RGB without spaces. Now you get a green g.
The same error is in Writer.
The behavior is different from MS Office and WordPad, SoftMaker and KingSoft Writer. Gnumeric gives a red g.
(In reply to Regina Henschel from comment #6)
> Your screencast does not contain the critical part. Mark the green G and
> enter a g.
Ah... on editing it takes the style from the character before.
Make me *bold*.
Make me *b * (continuation the style is not questionable)
Make *me* bold. (entering text after the e keeps the bold style)
Make *me *bold. (entering text before the b keeps the bold style)
Make *me* bold. (entering text before the b has no bold style)
Doing the same with colors it works similarly:
RedR RGreenG GBlue
(Font color set to red/green/blue until the next word, ie. including the character. R=Entered text is red, G=Green.)
Same is true for LibO and Office2010
This has another manifestation - simply changing the font (or format) affects characters not even selected - see new attachment107857.ods.
1. insert blinking cursor between "I" and "N" in cell B3 (don't select any characters, just put the cursor in that position)
2. set the font to Symbol, planning to type the U+2665 necessary to get the heart
result: see D3 – simply change the font without typing anything automatically changes the font for the existing characters!
to reproduce without the ods file:
1. set the font to arial
2. type two characters
3. position the cursor between the characters
4. change font to symbol
5. the whole cell changes to symbol on its own (the user desires to type new characters in symbol font
Created attachment 133410 [details]
steps for alternate aspect of bug described in comment
If you have a whitespace between the characters you can change the font being entered. The same is true for selections.
But anyway, I believe there are good reasons to keep the formatting as it is. The continuation of formatting until a whitespace character is more convenient as the rare cases when properties are changed arbitrarily. Of course, I might be wrong.
Heiko: I see it different. Perhaps the problem is clearer, if I describe it with markup, although that is not the internal representation:
The text has the form
<text:p text:style-name="Standard"><text:span text:style-name="myRed">R </text:span><text:span text:style-name="myGreen">G </text:span><text:span text:style-name="myBlue">B </text:span></text:p>
Now I select the G and press key g.
Expected: G has been replaced with g
<text:p text:style-name="Standard"><text:span text:style-name="myRed">R </text:span><text:span text:style-name="myGreen">g </text:span><text:span text:style-name="myBlue">B </text:span></text:p>
But I get
<text:p text:style-name="Standard"><text:span text:style-name="myRed">R g</text:span><text:span text:style-name="myGreen"> </text:span><text:span text:style-name="myBlue">B </text:span></text:p>
It seems, that LO does a "delete" followed by an "insert" instead of a true "replace". For an "insert" it is the correct behavior to continue the style of the previous character, but here a "replace" is intended and the undo names it "Replace". To get what you want, you have to insert the g after the G and then go back and delete the G.
(In reply to Regina Henschel from comment #11)
> Heiko: I see it different. Perhaps the problem is clearer, if I describe it
> with markup, although that is not the internal representation:
If we talk about overriding a character only, as you describe very clearly, with the intention to keep and harmonize the current workflow I have no concerns. But when it's about how insert/edit works, we should make sure to not harm any other use case.
So actually this is not a UX question but an ordinary bug. Removing the keyword.
(In reply to Heiko Tietze from comment #10)
> Of course, I might be wrong.
As someone who has been using this small portion (formatting) of the program 8 to 12 hours a day, seven days a week, abd using it only to create graphics (no math functions), I hope I can convince you that you are indeed quite wrong. There's no substitute for the understanding gained from spending hundreds of hours trying to make a super complex spreadsheet look right, and there's no substitute for the experience gained from being forced to keep proofreading the content of the spreadsheet and having to re-enter cells to correct the data or format. It's down here in the trenches that the faulty logic of the program makes itself so painfully apparent.
I'm making an elaborate representation of all of the songs of The Beatles - well over 200 - and each one has many complex sections. Each time I get to a new section or a new song I use similar functions of Calc. I'm only using less than 1% of the code you've written but I'm using that 1% in every possible way - if I can find a more convenient way to do any single operation it will save me hours in the long run because of the repetitive nature of what I'm doing. I've tried many different workflows.
I've tried this in Excel and Calc. Calc - on balance - has less problems and that's why I'm taking the time to try to convince you to fix it. Trust me - it needs fixing very badly. The way you've got it coded now is enough to make the user rip his or her hair out in large bunches. The user needs to be able to act on a selection without the program changing something that's not selected. I can't say it enough - it's not enough to code the program - you have to USE the program to see why your users are so frustrated.
(In reply to Regina Henschel from comment #11)
> It seems, that LO does a "delete" followed by an "insert" instead of a true
YES! When you select something, what you type should "replace" the text and retain the format. That's how users understand computers:
1. select something to the computer what you want to apply a command to
2. apply the command - it changes the selection
But the way Calc is coded, when you apply the command, it goes to an unselected part of the document and changes that!!!!
How can that possibly not be a bug? How can you trust and become intuitive about a program that keeps changing things you didn't ask it to change?
I admit that I do not know how to write a line of code, but I was a full-time professional software tester for 15 years and the bugginess this behavior is supported by every instinct I learned during that time, in addition to the thousands of hours I've spent as a user of this type of program.
Here's another way that this problem manifests itself, including a bizarre mystery I can't solve. In the attached .ODS file (10857-b.ods) there are steps and two cells that LOOK completely identical but the buggy behavior only occurs in one of them.
Created attachment 133428 [details]
This goes with the comment that references 10857-b.ods (steps in spreadsheet)
Created attachment 133429 [details]
steps for the comment referencing 10857-c.ods
The new attachment, 10857-c.odsm demonstrates (and includes steps and notes for) another buggy behavior that I believe shares the same root cause. I could give you 50 or 100 different sets of steps, each producing another result that appears to be a separate bug, but I'm pretty sure they all stem from the same code behavior that you guys are discussing - this thing about "not doing a true replace", but as you can see, it goes well beyond just "unexpected UI behavior" - it can cause behavior that is unequivocally buggy (i.e., the same steps produce different results in seemingly identical situations), as opposed to simply being different from Excel but consistently different.
I don't use Writer, but I tried the original steps and it did indeed occur in that program (but not in Word or Excel or any other non-Office program).
I believe everything is clear now and the bug can be fixed: instead of delete+insert the override function has to work as a true replace. More comments would add confusion only.
(In reply to Kevin from comment #13)
> I'm making an elaborate representation of all of the songs of The Beatles -
> well over 200 - and each one has many complex sections.
Hope you will share the result with the community so that everyone can get an impression of the power of Calc :-).
The design team has a nice blog for that purpose, in case you don't know how to do it.
Created attachment 134204 [details]
absolute simplest case
Reading some of the comments on other reports I'm starting to see that Calc differentiates between formatting set from within the cell versus to the cell itself. This attachment demonstrates the bug completely within a fresh cell - absolutely no complications.
*** Bug 112056 has been marked as a duplicate of this bug. ***
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
I agree that it is wrong behavior.
If you do the same text without spaces, so RGB, the selected G will be replaced with a green g.
(In reply to QA Administrators from comment #22)
Still unchanged in LODev7.0
*** Bug 108333 has been marked as a duplicate of this bug. ***