Description: When pasting any of the decimal numbers in the attachment to Writer as "Formatted text [RTF]", "HTML (HyperText Markup Language)", "DDE link" or "Unformatted text", the formatting isn't preserved. Steps to Reproduce: 1. In the attachment, select any cell containing a decimal number. 2. Copy the selected cell to clipboard. 3. Open Writer. 4. Press Ctr + Shift + V (or Edit → Paste special...). 5. Select "Formatted text [RTF]", "HTML (HyperText Markup Language)", "DDE link" or "Unformatted text" 6. Compare the pasted number with the original. Actual Results: Only rounded (whole) number is pasted. Expected Results: The original decimal number should be pasted. Reproducible: Always User Profile Reset: Yes Additional Info: The same thing occurs when accidentally cutting/changing any of the numbers and then pressing Ctrl + Z. The numbers have conditional formatting applied. The bug is present in a recent version of LibreOffice as well. User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Created attachment 137166 [details] A sample file.
The issue comes with the cell format, the paste is done following the cell style format not the direct cell format. Cell has the style 'Whole numbers' modified with a direct format, 'Whole numbers' has no decimal places, how the copy is done. Applying the 'Decimal numbers' style to cell and then copying works fine.
** 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
According to comment 3, this is no copy/clipboard/paste issue. The issue here is that the cell has a style ('Whole numbers') with style number option 'Decimal places' with '0'. But when opening the file, in cell D2 the number HAS decimal places. If applying another style and re-applying 'Whole numbers' style, the decimal places are correctly displayed. Seems to be a problem of conditional formatting as there it decides if cell has a number format with or without decimal numbers. Changing summary from '"Paste special..." from Calc to Writer doesn't preserve formatting' to 'Conditional formatting: false cell number format displayed that's defined by a cell style'. Anyway, still reproducible. Version: 6.2.0.0.alpha1+ (x64) Build ID: ae9f37ba753519ae4a2ae6384d052d417359602f CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-23_02:03:22 Locale: de-AT (de_AT); Calc: CL
I'm still not sure what is the exact bug here. We need to better explain it. 1. C2:D2 have CF: - if cell value is INT(C2), apply style Whole numbers (it doesn't) - if cell value is not INT(C2), apply style Decimal numbers (which it does for C2 and D2, can be seen if Decimal numbers is red). 2. C2 cell value is 90,9 but instead of seing Decimal numbers (from CF) I guess we see applied direct formatting that overrides style formatting (see Bug 93300) and that is Number with 0 decimal places. 3. What I don't understand is why D2 on fileopen shows Decimal numbers although it has the same direct formatting as C2. Is it related to Bug 114860 or there's some "perfectly logical explanation". 4. D2 has value of "4.90649064906491" and cached cell content of "5". Why does it show 4,906 on fileopen? Why does it change to 5 on recalc or some change? I guess there's the answer to the original bug report that 5 is pasted (similat to what Thomas noted). Since recalc changes view, I'll set to minor. Different with OO 3.3 (90,9 and 5), LO 4.0 and LO 4.2 (90,9 and 4,906). Repro 6.0 and 6.3+ (91 and 4,906).
Dear ask4support, 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 https://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
Dear ask4support, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
For the copying purposes, the only format that is being considered is the main format for the cell. IOW, conditional formatting is correctly considered for displaying within Calc, but it is ignored for copy+paste to Writer. For example, setting the main cells format to "Default" in the provided attachment in comment #1, the cells are displayed according to their conditional format within Calc: 446 -> "#,##0" (Whole numbers style) 90.9 -> "#,##0.###" (Decimal numbers style) 4.906 -> "#,##0.###" (Decimal numbers style) That last 4.906 is the display (CF) of the real value resulting from 446/90.9. When copying these cells to writer, they are pasted as: 446 90.9 4.90649064906491 Now change the main cell format from "Default" to "#,##0.00" and repeat the copy+paste to Writer, which results in: 446.00 90.90 4.91 So, Calc respects the CF for displaying the cells (independently of the Ctrl+1 format), and the copy+paste to Writer depends on the main format in Ctrl+1. Whether there is a bug (somewhere) or it is all expected behavior, I'll leave it to others.