When merging a cell containing marked up text (underline, bold, italics) with an empty cell, the result shows the text but without the earlier markup. How to reproduce: 1. Enter some text in a cell, and then use one or more markup options. 2. Select that cell and one next to it and merge them. 3. In the dialog that asks to move the contents of the hidden cells to the first cell, select Yes. Actual result: the markup of the text is now gone. Expected result: the markup of the text stays as it was before Tried 11th of March 2015 on LibreOffice Calc 4.3.2.2
Reproducible with LO 4.4.1.2, Win 8.1 Note to Step 2: It is not reproducible when merging the cell with a cell right to or below that cell. It is only reproducible when merging the cell with a cell above or left to that cell.
(In reply to A (Andy) from comment #1) > Reproducible with LO 4.4.1.2, Win 8.1 > > Note to Step 2: > It is not reproducible when merging the cell with a cell right to or below > that cell. It is only reproducible when merging the cell with a cell above > or left to that cell. Can confirm for 4.3.2.2
** 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 on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
** 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 on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
Still reproducible in : Version: 6.2.0.0.alpha0+ (x64) Build ID: 8b1501d80dc9d3f42c351c6e026fa737e116cae5 CPU threads: 2; OS: Windows 6.1; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-09-22_23:19:22 Locale: bs-BA (bs_BA); Calc: threaded Tried also in LO 3.3.0 and OOo 3.3.0, it inhereted from OOo.
Dear harm.deweirdt, 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
Still reproducible with Version: 6.3.5.2 (x64) Build-ID: dd0751754f11728f69b42ee2af66670068624673
*** Bug 134757 has been marked as a duplicate of this bug. ***
*** Bug 138082 has been marked as a duplicate of this bug. ***
*** Bug 136505 has been marked as a duplicate of this bug. ***
Example is given in duplicate 138082 with file attachment 167112 [details] compared in MSO and LO before as attachment 167110 [details] and after as attachment 167111 [details]. There are 2 issues here: IMO requests shouldn't be accepted unconditionally as requested: "look for the 1st cell with contents and keep that format" but instead to add check mark on Merge Cells dialog to say: "keep the format of 1st non-empty cell" and remember last status. But it may complicate .. let's call UX to decide. Other issue is Help which doesn't explain that Merged Cells adopt the format of the first cell and it should. With this bug it should also explain that it adopts the format of the first cell with format. This is a note to ask for Documentation change after this bug is decided.
(In reply to Timur from comment #10) > *** Bug 136505 has been marked as a duplicate of this bug. *** Not quite sure what route I took* but my search for "Merged Cell Format" returned about five reports - none of which were relevant. * Sometimes I go in through Bugzilla and sometiimes through the feedback in Help. Sometimes I'm already "logged in" and other occasions require login. On this occasion the presented page was not what I was accustomed to so after having formulated my query with little relevance I then exited and re-entered via the Feedback process simply to file what appeared to be a unique report. Sorry -It Happens
Sorry chaps, message clashed and I was apparently posting my apology to the wrong one
(In reply to Timur from comment #11) > Example is given in duplicate 138082 with file attachment 167112 [details] > compared in MSO and LO before as attachment 167110 [details] and after as > attachment 167111 [details]. > > There are 2 issues here: > > IMO requests shouldn't be accepted unconditionally as requested: "look for > the 1st cell with contents and keep that format" but instead to add check > mark on Merge Cells dialog to say: "keep the format of 1st non-empty cell" > and remember last status. > But it may complicate .. let's call UX to decide. > > Other issue is Help which doesn't explain that Merged Cells adopt the format > of the first cell and it should. With this bug it should also explain that > it adopts the format of the first cell with format. > This is a note to ask for Documentation change after this bug is decided. I believe there are more than two issues. I can "Live" format a text string to reflect many different fonts, sizes and colours which all reproduce faithfully in the cell. They also reproduce when the cell is "drag" copied and with Ctrl+C > Ctrl+V. Merge & Centre also reproduces the variations if they are contained in the first cell. I think it's almost an exercise in "mind reading" to ascertain the users' hopes & dreams
*** Bug 93202 has been marked as a duplicate of this bug. ***
*** Bug 136405 has been marked as a duplicate of this bug. ***
Now that we have 5 duplicates, this is High priority. (But it doesn't mean it will be resolved sooner, it still needs a volunteer). Bug 93202 shows a consequence: in addition to format also formula is lost. So this is not a minor issue. I still think we should have a check box for this.
Excel takes the format of the first non-empty cell into the merged cell. No question or confirmation what to pick. For sake of familiarity we could do the same. But we have to store the cell formattings in case the user un-merges later, which Excel cannot. <green><yellow><red> => <green> <><yellow><red> => <> (no format) <green><yellow>123<red>456 => <yellow>123 <green><>123<red>456 => <>123 (no format) (IMHO not highly important)
I don't see this as an enhancement (yes for format) but as a bug (because of lost formula, of which user is not aware immediately).
*** Bug 153899 has been marked as a duplicate of this bug. ***
I have split again the issue with a formula being replaced by its static result, as I think they need to be tracked separately and are of different importance. Formatting issue is still reproducible in: Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded One cell *has* to be the main one when merging, as some formatting can't be mixed (for example, the cell background). However, text values can have a mix of formatting, and that should not be lost in the process.