Created attachment 133498 [details]
All steps and analysis included in spreadsheet

When I say "reproducible: always", I mean with this spreadsheet. I believe that the bug relies on something in the user's workflow that results in a corrupt file that - if you monkey around with it - can be "cleaned". So if you're going to say "can't reproduce", that's possible if you're starting from scratch or if you've done a lot of editing on my attached spread. But if you open it up and follow the steps meticulously, the bug will always occur. I can't write code, but I'll bet if you just look at the underlying code that displays the cells in the spread you'll see the problem - whatever is telling the program internally what the font is gets corrupted and all the symptoms branch out from that.

Created attachment 133778 [details]
simplest example of the problem - just one cell

This spreadsheet has only one cell - it is Calibri italic.

1. select the cell
observe: the formatting toolbar's italic button is not selected
2. click the button (or type control+I) - the button is selected
3. click again to deselect (or type contro+I again) 
bug: the button is deselected, but the contents of the cell remain italic - the contents never change throughout the steps - the UI tells us the wrong state and prevents us from changing it - even with only a single cells selected.

I don't understand why sometimes simply toggling between italic and non-italic a few times will produce the desired result, but in this case it's really stuck. I hope you can examine the .ODS file as see what has gone wrong in the underlying code that tells the UI what to show the user. This is a frequent problem with Calc.

Aha! I just noticed that the cell is set to Number instead of Text - perhaps it thinks the "/" (which means that C is in the bass of an A minor 7 chord) is really "divide" and is therefore showing a formula? Setting the cell to Text does cause the button to show Italic, but clicking it still doesn't remove the italics.

If you do right-click - clear direct formatting (or Ctrl-M) you can reset the cell formatting to default.

If you unzip the .ods file and look inside the content.xml (I usually use this first http://xmlbeautifier.com/ ), you will see the text element:

<text:p>
<text:span text:style-name="T1">aceg/C</text:span>
</text:p>

The T1 style definition is

<style:style style:name="T1" style:family="text">
<style:text-properties fo:font-style="italic" style:font-style-asian="italic" style:font-style-complex="italic" />
</style:style>

So apparently there should be a style called T1, but it does not appear in the style list.

How was this file created? In LibreOffice? In Microsoft Office? In Apache OpenOffice? In something else?

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.

Hi - I have a huge file that uses formatting but no formulas that began life in Excel 2010, the went to Calc 5.2 then Calc 5.3. When I find a bug I paste cells from that master file into a fresh Calc 5.3 file, so that's the history of the two attachments.

> If you do right-click - clear direct formatting (or Ctrl-M) you can reset
> the cell formatting to default.

yes, this works - it's not the cell location that gets corrupt - it's the cell contents


> If you unzip the .ods file and look inside the content.xml (I usually use
> this first http://xmlbeautifier.com/ ), 

This looks interesting but I can't figure out what you mean. WinRAR won't recognize the .ODS file as something that can be unzipped, xmlbeautifier.com also doesn't recognize it. The .ODS opened in Notepad.exe but the results didn't look promising. I tried "save as" within Calc to save as .XML and it returned "the file could not be written". 

But since you can see the internal xml or whatever it is, doesn't that prove that this is a bug that needs to be fixed, rather than "unconfirmed". It doesn't really matter how the cell got the way it is - should Calc be programmed such that it will repair whatever is going on in the XML part of the ODS so the user's commands will be obeyed? (Obviously I'm not an engineer, but common sense says that the user selects something, then chooses a command - if it doesn't work, it's a bug, right?)

(In reply to Kevin from comment #6)
> Hi - I have a huge file that uses formatting but no formulas that began life
> in Excel 2010, the went to Calc 5.2 then Calc 5.3. When I find a bug I paste
> cells from that master file into a fresh Calc 5.3 file, so that's the
> history of the two attachments.

Do you by any chance have such a *pure* Excel file?

> Do you by any chance have such a *pure* Excel file?

Yes - Uploading as beatles-form4+chords.xlsx (it's a mess - 2 months downrev - but it has never been saved by Calc)

Created attachment 133829 [details]
"pure excel" file as requested

Created attachment 133937 [details]
another file that I hope will help you change this from "unconfirmed" to new

Maybe you can confirm it with this file. This is a real bug and the corruption it introduces is likely a symptom and/or cause of a much wider disease. There has to come a point where you guys step back and realize that while these individual items don't rise to the level of alarming you, they're part of a much larger pattern (that the whole formatting UI is badly and embarrassing broken). Someone with real coding expertise needs to review the formatting code from top to bottom and at the very least fix the bugs that are not present in Microsoft Excel.

Created attachment 134126 [details]
Please open this and fix it - this is HORRIBLE people! this bug should not be unconfirmed after all this time - this is absolutely crippling - embarrassing - sadistic - a vile stain on Doc Foundation

(In reply to Buovjaga from comment #5)

Did that file help? I've uploaded another example file of another aspect of this problem. The bottom line of this bug is that it makes a person edit one cell at a time! It defeats the whole idea of saving time with computers. This is really REALLY HORRIBLE!!!!!!!!!

(In reply to Kevin from comment #10)
> Created attachment 133829 [details]
> "pure excel" file as requested

Can you point to some exact cell here, which does not display Prestige Elite in the font dropdown field even though *the cell content starts with Prestige Elite*?

We need to focus on this untainted XLSX file, because do not know how you arrived at the situation described in 108041.ods

I looked into the sharedStrings.xml which contains font definitions matching text strings.
For example C1234 is defined in the .xml to start with Prestige Elite and it is shown correctly in LibreOffice. Even if I save as .ods and reload the file.

For example D1228 does not start with Prestige Elite and thus Source Sans Pro Black is shown in the font dropdown, if you just navigate to the cell. If you start to edit the cell and move inside the "FFoF Fooo" part, it displays the font as Prestige Elite just like is defined in the sharedStrings.xml mapping.

(In reply to Buovjaga from comment #14)

Did you try my new file?

I briefly experimented with substituting Prestige Elite for Courier New because I thought it might work better for the b and # symbols, but I abandoned the idea and have removed all instances of Prestige Elite from my document. Only a small fraction of the cells ever had prestige elite applied to them. The cells I copied to create the new attachment (https://bugs.documentfoundation.org/attachment.cgi?id=134126) never had Prestige Elite as far as I know.

I don't understand the approach to this bug. Why does the history of the document matter. I would expect Calc to be able to open any .xlsx or .ods and "cleanse" each cell of any strange headers or xml or whatever other kind of coding and put them into the clean orderly format that Calc expects to see when it creates its own document. The ability to open pre-existing Excel files without corrupting them has got to be near the top of the list of requirements

Created attachment 134137 [details]
file created entirely within 5.3.3.2 - no prestige elite

I accidentally uploaded this to the wrong report earlier. This file is created totally from scratch. Prestige Elite and Excel are not involved. All you have to do is create new cells that use more than one font and mixed attributed like superscript, bold, and grey font color. At a certain point you will lose the ability to do a mass-change of all of the font sizes (or other attributes) of a selection of more than one cell.

The ability to select a range of cells and change them all to 10 pt size is not minor or trivial or an enhancement. It's a fundamental requirement of the program. This is why I'm so horrified that you guys did all the work to add what you ironically call "styles" without allowing a "style" than lets you change only one class of attribute such as changing to 10 pt and NOT changing anything else. So not only is "styles" a cruel joke, but the user can't even manually select a range of cells and change the desired attribute with the formatting toolbar - much less save time with "styles".

I have now been using this program full time for almost 2 months - 7 days a week - no formulas, no math - just formatting. It is broken - not trivially broken, not broken in a minor way, not broken in an "enhancement request" way - it is fundamentally broken.

If you experiment with the file created entirely within 5.3.3.2 you can get all sorts of interesting variations on the bug. For example:

1. Select only D15 and D16
2. change font size to 12 pt
result: It does indeed change all characters to 12 pt, but it removes all other attributes like bold
3. repeat with only D13 selected
result: It behaves correctly, retaining all attributes other than size

CORE BUG: A character has a variety of attributes - font face, size, bold, italic, underline, superscript, color. The user expectation is to be able to deal with these attributes INDIVIDUALLY - e.g., to change the size WITHOUT changing the other attributes. This is what the rest of the world thinks of when they think of "styles". In any other suite of programs you can create a style called "12 pt" that will change everything selected to 12 pt and do NOTHING ELSE - whether the selection is a range of characters within a cell, or a range of cells within the spreadsheet. In lieu of having working styles, which Calc most certainly does not in spite of the fanfare surround the release of this "feature", it's even more important that they user should be able select multiple cells and use formatting toolbar to workaround the lack of style functionality that has been present in Microsoft for decades.

Created attachment 134138 [details]
bare bones steps with only calibri and courier new in virgin file

(In reply to Buovjaga from comment #14)

Here you go: 108041-with steps to create your own from scratch.ods - attached

This will allow you to reproduce the bug from absolute scratch on your own system. The symptom reproduced with this scaled back version may cause you to say "oh, well, it's trivial because there are many cases where it works properly (for example selection the first 2 cells only)" - but this bug works like a mushroom cloud once you start working with a spreadsheet. I'm currently trying to show you one simple symptom with an absolute minimum of steps and required complications. I'm almost certain that everything else stems from some very simple flaw in the code, and that the whole problem of Calc and formatting stems from the misunderstanding of what the word "style" means to your users.

Created attachment 134139 [details]
file for comment 19

Something may be learned from this test:

1. open 108041-even-simpler.ods in Microsoft Excel 2010

result: Excel reports finding and fixing an error:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<recoveryLog xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"><logFileName>error055000_01.xml</logFileName><summary>Errors were detected in file 'C:\Users\User\Desktop\108041-even-simpler.ods'</summary><additionalInfo><info>Excel completed file level validation and repair. Some parts of this workbook may have been repaired or discarded.</info></additionalInfo></recoveryLog>

2. try the steps in Excel - no bug. Excel unfortunately doesn't say what it "repaired", but my guess is that it's the same thing that causes Calc's formatting toolbar to display incorrect font information.

SPEC QUESTION: If a cell that contains multiple fonts and/or formats is selected in Calc (not entered, just the whole cell selected) what is the formatting toolbar SUPPOSED to display to the user? Just a blank white space? Because if that's right, there is often a bug even before you start doing any steps. In other words, if a cell has two fonts, and the toolbar shows anything other than blank, you've already primed the system for bugs to occur downstream, right?

(In reply to Kevin from comment #19)
> (In reply to Buovjaga from comment #14)
> 
> Here you go: 108041-with steps to create your own from scratch.ods - attached
> 
> This will allow you to reproduce the bug from absolute scratch on your own
> system. The symptom reproduced with this scaled back version may cause you
> to say "oh, well, it's trivial because there are many cases where it works
> properly (for example selection the first 2 cells only)" - but this bug
> works like a mushroom cloud once you start working with a spreadsheet. I'm
> currently trying to show you one simple symptom with an absolute minimum of
> steps and required complications. I'm almost certain that everything else
> stems from some very simple flaw in the code, and that the whole problem of
> Calc and formatting stems from the misunderstanding of what the word "style"
> means to your users.

Ok, thanks. As this is a very old bug, I managed to find an existing report and I will close this as duplicate.

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