Description: Calc makes changes to one attribute when asked to make changes to another attribute (which it doesn't change! But that's in a different report.) Steps to Reproduce: 1. load the attached spreadsheet 2. try to change the font SIZE of the specified cells Actual Results: it changes characters that were regular to bold without being asked Expected Results: 1. make a selection 2. apply a command - it should do what you asked it to do and nothing more Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Created attachment 134055 [details] steps included in spreadsheet for 108559
Confirmed in - Version: 5.5.0.0.alpha0+ Build ID: 6ab249ea6aecef5d3f35d624622a368061cad9c3 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group - Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e - Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a) - LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Created attachment 134117 [details] alternate steps and demo to shed light on the core problem
As attachment 134117 [details] tackles the core issue, lets focus this bug on it. So lets look at the code. <style:style style:name="ce1" style:family="table-cell" ...> <style:table-cell-properties ... /> <style:paragraph-properties ... /> <style:text-properties fo:color="#ffffff" ... fo:font-weight="bold" ... /> </style:style> <style:style style:name="T1" style:family="text"> <style:text-properties fo:font-weight="normal" ... /> </style:style> <style:style style:name="T2" style:family="text"> <style:text-properties fo:font-weight="bold" ... /> </style:style> <table:table-cell table:style-name="ce1" ...> <text:p>DD D <text:span text:style-name="T1">o</text:span> <text:span text:style-name="T2">D</text:span> <text:span text:style-name="T1">o</text:span></text:p> </table:table-cell> What can be seen is that 'DD D' is set to bold at the cell level and not at the span level, so from this view, it is understandable that when you paste the beginning 'DD D' that it wouldnt be set to bold, as it would look like so. <table:table-cell table:style-name="ce1" ...> <text:p>DD D <text:span text:style-name="T1">o</text:span> <text:span text:style-name="T2">D</text:span> <text:span text:style-name="T1">o DD Do</text:span> <text:span text:style-name="T2">D</text:span> <text:span text:style-name="T1">o</text:span></text:p> </table:table-cell> So not sure what could be done differently to make this work as expected, when the cell contents wasnt fully created with direct formatting in cell edit mode. @Eike: Any thoughts?
>So not sure what could be done differently to make this work as expected, when the cell contents wasn't fully created with direct formatting in cell edit mode. I'm thrilled to see that you're finally looking at the code. Can't you now just look at the corresponding code for Excel to understand why it works properly in that program? Also, why does the code you cite contain this: <text:span text:style-name="T1"> ? I never applied any styles in the creation of the spreadsheet.
(In reply to Kevin from comment #5) > I'm thrilled to see that you're finally looking at the code. Can't you now > just look at the corresponding code for Excel to understand why it works > properly in that program? Not likely as its a coding issue and not a xml issue. Was the document originally created in excel? > Also, why does the code you cite contain this: > > <text:span text:style-name="T1"> ? > > I never applied any styles in the creation of the spreadsheet. Direct formatting applied at the cell level or within a cell is stored as styles.
(In reply to Yousuf Philips (jay) from comment #6) > Was the document > originally created in excel? No - in fact, you can create this bug like this: 1. type: control+B, B, spacebar, control+B, R (this gives you a bold B and a regular R 2. copy everything you just typed, hit spacebar and paste voilà - the bold B is now regular - this is not "trivial" and it's not an enhancement - it's an appalling embarrassment - an absolute contradiction of decades of collective wisdom on how user interfaces should work - and something that should be fixed immediately so as not to further tarnish the reputation of your project. > Direct formatting applied at the cell level or within a cell is stored as > styles. As I've made abundantly clear, I think the implementation of "styles" in LibreOffice is an absolute travesty - if any of that code (and I use the term advisedly) is at work in the direct formatting bugs that seems like the first place to look for the root cause.
(In reply to Kevin from comment #7) > 1. type: control+B, B, spacebar, control+B, R (this gives you a bold B and a > regular R Yes your initial control+B applies bold to the cell and not to the 'B', but if you press F2, then followed your sequence, it would work correctly. I tested your sequence in excel 2010 and it did result with the same behaviour. There isnt much left to discuss here until a dev looks at the issue and give his/her input, so lets see what happens. Bubli: Any thoughts on this issue?
> Yes your initial control+B applies bold to the cell and not to the 'B', but > if you press F2, then followed your sequence, it would work correctly. > > I tested your sequence in excel 2010 and it did result with the same > behaviour. Oh God - you're right. So instead of something that's right in Excel and wrong in Calc, it's something that's wrong in both. This is a painful reminder of why I switched to Libre Calc in the first place. I tried the same sequence in both Word and Writer, in both tables and in normal paragraphs, and it worked logically in all cases. What you copy should be what you paste. Am I wrong? Can you describe any logical reason why you would want a hidden attribute of a cell to override what you've copied onto the clipboard? In any case, thanks for showing the workaround. I'll try to adapt my work flow to hit F2 before typing anything. NOTE: This doesn't invalidate the initial report as represented by 108559.ods. If you open that in Excel, the bug doesn't occur.
(In reply to Kevin from comment #9) > I tried the same sequence in both Word and Writer, in both tables and in > normal paragraphs, and it worked logically in all cases. What you copy > should be what you paste. Am I wrong? Can you describe any logical reason > why you would want a hidden attribute of a cell to override what you've > copied onto the clipboard? Well when you copied the 'B' it didnt have bold applied to it, as it was applied at the cell level, it just appears bold as there was no non-bold applied to it. Same concept can be seen in Writer with these steps. 1. Open Writer 2. Set Heading 1 (Ctrl + 1) 3. Type 'B ' 4. Disable bold 5. Type 'R ' 6. Copy 'B R ' 7. Paste > In any case, thanks for showing the workaround. I'll try to adapt my work > flow to hit F2 before typing anything. Yep F2 is the only way to make sure direct formatting is applied on the paragraph/text level and not the cell level. > NOTE: This doesn't invalidate the initial report as represented by > 108559.ods. If you open that in Excel, the bug doesn't occur. Lets see what the calc dev says. :D
** Please read this message in its entirety before responding ** 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! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to Kevin from comment #0) > observe: Cells B4, C3, C4 and C5 are drawn as Courier New 8pt >1. hold down control and select Cells B4, C3, C4 and C5 >observe: Calc's Formatting toolbar indicates that these cells are already >at 9pt – this is a different bug Not bug, just you may not differentiate direct, cell and character format. > 2. To workaround the above bug, set the font size to 6pt and then 9pt – >this seems to clear whatever corruption is preventing the cells from being >editable No need. > NEW BUG: Note that the o's in Cell B4 have been changed to bold – no >apparent rhyme or reason – this kind of this happens ALL the time in ALL >manner of ways. This program in a disgraceful state. There was cell direct format to bold and it's back now. (In reply to Kevin from comment #3) > Created attachment 134117 [details] > alternate steps and demo to shed light on the core problem Also no repro with 6.3 and 6.5+.