When you try to use Data "Formula to Value" , it don't preserve line break with multi-line text value. At UI level : the rendering becomes different and not lisible, it's a very severe issue, because this is a very frequent case ... To reproduce , simply enter un text with line breaks (Ctrl enter) in a cell, in a second cell , create a formua =1st Cell, Then call menu Data / Compute / formula to value : you see the problem In xml content of Saved file : original value is : <text:p>aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa</text:p> <text:p>Bbbbbbbbbbbbbbbbbbbbbbb</text:p> <text:p>Cccccccccccccccccccccc</text:p> replace value is : <text:p>aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa <text:line-break/>Bbbbbbbbbbbbbbbbbbbbbbb <text:line-break/>Cccccccccccccccccccccc </text:p> It is coherent
This issue is for all libre-office versions I know.
Description , correction : It is NOT coherent
Repro Version: 6.1.3.0.0+ (x64) Build ID: 974ad88c876cfabe0fb334b29cc04bb8a06fd5e9 CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:libreoffice-6-1, Time: 2018-09-21_15:19:50 Locale: es-ES (es_ES); Calc: group Version: 6.2.0.0.alpha0+ (x64) Build ID: 3208fcb3a36d75d6290d9c548430682f153b09db CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-09-20_22:43:20 Locale: es-ES (es_ES); Calc: threaded Maybe one for @Kohei
Formula to value entry was added in https://cgit.freedesktop.org/libreoffice/core/commit/?id=f3fae7d3c64db62568290f105d8404f037793945 However it was greyed out in previous versions selecting the second cell. At some point in 5.3 it became active. I've tried to bisect it but somehow the bisection result isn't accurate...
@Kohei, I thought you could be interested in this issue...
Dear antoine, 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
Dear antoine, 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
Repro using Version: 7.4.3.2 (x64) / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 12; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL
Consider the formula in A1: =1&CHAR(10)&2 Converting "Formula to Value", the visible result in the cell is "12", but the formula bar has the two lines. And "=LEN(A1)" gives 3. This is beautifully explained in comment 0, where paragraph-vs-linebreak difference is discussed.
Problem is, the formula multiline result is converted to a plain simple text string, which when displayed is not treated special in any way i.e. no linefeed / multiple paragraph detection whatsoever. Furthermore, when storing and loading such string cell with <table:table-cell office:value-type="string" calcext:value-type="string"> <text:p>aaa<text:line-break/>Bbb</text:p> </table:table-cell> the embedded <text:line-break/> is ignored and skipped (maybe on purpose, didn't check), so a previous LEN(A1)=>7 becomes 6. Both, display and store/load problems, could be solved if instead a cell with an EditTextObject would be created for a multiline result, properly using the document's SharedStringPool. See https://opengrok.libreoffice.org/xref/core/sc/source/core/data/column4.cxx?r=1a7913c1#492 and for inspiration https://opengrok.libreoffice.org/xref/core/sc/source/core/data/clipcontext.cxx?r=20b8c7f3#254 The mere display of such embedded linefeed *maybe* could be solved by adding CHAR_LF to ScDrawStringsVars::HasEditCharacters() in https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/output2.cxx?r=f9395a12#810 that in https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/output2.cxx?r=f9395a12#1731 forces the use of an EditEngine. But that wouldn't address the store/load omission of the linebreak. So rather keep the display as a visible indicator until solved/clarified.
Hum.. that appears (I didn't investigate how) to be fixed already on current trunk for 7.5, at least I can't reproduce there. Also loading such string cell with embedded <text:line-break/> preserves it.
(In reply to Eike Rathke from comment #11) > Hum.. that appears (I didn't investigate how) to be fixed already on current > trunk for 7.5, at least I can't reproduce there. Also loading such string > cell with embedded <text:line-break/> preserves it. maybe 3772f18266c3347e8fd60eb8f058d65328c400b4 ?
Crap, no. If automatic spell-checking is enabled and there's a spelling error in the created string then an EditCell view is forced and that displays the line break.
Creating an EditCell of embedded <text:line-break/> apparently was fixed by commit 8f5f0c754222425af019a9fdc1ba47d72c541d9e.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/40a59e3e58de1c3f60ae52d09fbc386399f8f122 Resolves: tdf#120190 Handle multiline string in Formula to Value conversion It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/17b302b092b5c90552720097fe87c8eedc8f83df Related: tdf#120190 Factor out ScDocument::CreateSharedStringTextObject() It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified with Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 52c75986adc2b370eb55ce918ab1db0a95831c83 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (es_ES); UI: en-US Calc: CL threaded
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c5844bad90dd056ca533ba86443e179ee4611f2c tdf#120190: sc_pdf_export: Add unittest It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.