When rows in Calc are formatted via Format - Rows - Optimal Height the value of "Add" seems to be not saved in the document. It ssems that the value exists once in LibreOffice (!) and that is in effect until LibreOffice is closed. It also affects other spreadsheet documents edited at the same time or after the first document is closed. When the formatted spreadsheet document is opened after LibreOffice is started newly the Add value used at formatting before save is no longer available. At Format - Rows - Optimal Height the Add value 0.00 is shown and the "Default Value" is marked. I think that this behavior is not good, but I don't know if it is a bug or if it is correct (means LO works as designed). The behavior can be reproduced with a new spreadsheet document: - File - New - Spreadsheet - Fill values in some cells - Select the whole sheet - Format - Rows - Optimal Height: set any value > 0, "Default Value" is not marked - Save the document and close it (- open any other spreadsheet and look to Format - Rows - Optimal Height: the Add value set before is shown) - Close LO - Start LO again - open the saved document - Format - Rows - Optimal Height: Add value 0.00 is shown, "Default Value" is marked also reproduced with Version: 6.0.0.0.alpha0+ (x64) Build ID: 2404a17e157273430d40ceaa1ab1275e7b50ba6e CPU threads: 2; OS: Windows 6.19; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-06-16_23:41:27 Locale: de-DE (de_DE); Calc: group
Created attachment 134097 [details] gdbtrace with LOv6.0alpha
reproduced the behavior with Version: 6.0.0.0.alpha0+ Build ID: 2404a17e157273430d40ceaa1ab1275e7b50ba6e CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-06-17_03:43:01 Locale: nl-BE (en_US.UTF-8); Calc: group
No repro with 3.6, so regression. Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
Did this ever work? I can't see how this could have worked in the past. As far as I can see the feature calculates the optimal row height + the extra height and sets this as manual row height.
Created attachment 134340 [details] Screenshot from 3.6 after saving and reloading
I have reproduced the bug also with LO 3.6.7 (Win 10). But: Until now I havn't paid attention to the Quickstarter option of LibreOffice, because I don't use it. When this option is active at the start of LO, LO is kept in memory at Close and also the Add value for "Optimal row height" is kept. In my tests with activated quickstarter I've got the same result, that Buovjaga got at his test. I have tested this in Windows not only with LO 3.6.7, but also with LO 5.4.0 rc1 and with LO 6.0 alpha. To ensure that at the reopen of the saved spreadheet the Add value for Optimal Row Height is taken from the file and not from LO kept in memory, LO must be closed completely before, means Quickstarter was not active and/or it must be removed from the memory by Task Manager or by Logoff or by Restart of the computer. Buovjaga, are you sure that LO was completely closed and removed from memory between Save and Reopen at your test?
(In reply to Stefan_Lange_KA@T-Online.de from comment #6) > Buovjaga, are you sure that LO was completely closed and removed from memory > between Save and Reopen at your test? No, I did not close it. It is true that now I see the file with the wrong result.
Reply to Comment 4 of Markus Mohrhard 2017-06-27 23:52:32 UTC : I have looked in the standard ISO/IEC 26300-1 "Information technology — Open Document Format for Office Applications (OpenDocument) v1.2 — Part 1: OpenDocument Schema" for a parameter usable to save the Add value for Optimal Row Height, but I haven't found. Because it is a row property I would expect as parameter an attribute of "style:table-row-properties" like "style:use-optimal-row-height" or "style:row-height" (seen in content.xml = part of ods files), but I've found only this: 17.17. 17.17 <style:table-row-properties> The <style:table-row-properties> element specifies formatting properties for table rows. The <style:table-row-properties> element is usable within the following elements: <style:default-style> 16.4 and <style:style> 16.2. The <style:table-row-properties> element has the following attributes: fo:background-color 20.175, fo:break-after 20.177, fo:break-before 20.178, fo:keep-together 20.193, style:min-row-height 20.312, style:row-height 20.340 and style:use-optimal-row-height 20.384. The <style:table-row-properties> element has the following child element: <style:background-image> 17.3. IMHO this confirms the assumption of Markus Mohrhard and I guess that the value cannot be saved without an enhancement of the standard.
** 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
The bug is still present in Version: 6.0.5.2 (x64) Build-ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16 CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: CL and also in Version: 6.0.6.0.0+ (x64) Build ID: dd9232a6b2bcd32c7279e1476445214c6bb9e417 CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:libreoffice-6-0, Time: 2018-06-30_06:57:28 Locale: de-DE (de_DE); Calc: CL as well as in newest versions of LOdev 6.1 and 6.2 Version: 6.1.0.0.beta2+ (x64) Build ID: 76c0b3c516f6b0d43136522b4d476eb60211cec1 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:libreoffice-6-1, Time: 2018-07-01_01:06:16 Locale: de-DE (de_DE); Calc: CL resp. Version: 6.2.0.0.alpha0+ (x64) Build ID: b0e291a7efcd3af2a72d0b622b1f1b84723f011f CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-06-30_23:43:40 Locale: de-DE (de_DE); Calc: CL "Inherited From OOo" was (correctly!) set already in June 2017 and I have tested once more with LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Dear Stefan_Lange_KA@T-Online.de, 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
The bug is still present in all actual versions: ################ Version: 6.2.6.2 (x64) Build-ID: 684e730861356e74889dfe6dbddd3562aae2e6ad CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded ################ Version: 6.3.0.4 (x64) Build-ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded ################ Version: 6.3.1.0.0+ (x64) Build ID: 60b6288bc1aec17d04b45f62ba6f117fc43f8ab4 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:libreoffice-6-3, Time: 2019-08-04_12:12:28 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded ################ Version: 6.4.0.0.alpha0+ (x64) Build-ID: 3e64065612acec2eb29aa21e2b515953422256d7 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-08-15_22:57:26 Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded ################ "Inherited From OOo" was set already earlier.
I still see this bug in 6.4.7.2: I select a row by clicking left of it (the row contains a longer text line in the first column that is to be word-wrapped). I select "Optimal height", and the height of the row changes correctly. At some later time, the row's height is still back at one text line, showing only the end of the wrapped line. This happens while the document is kept open for a longer time (no need to save and load).
Proposal to solve the problem: Until now no way was found to save the Optimal row extra height value in the sheet document. Could the problem be solved by introducing a new entry in settings.xml - nearly so as it was made in LO 7.2 for the setting "KeepRatio" in Image Properties Dialog [until now only for Writer, not yet in the Position and Size dialog of images in Calc]? Example of an existing entry in settings.xml: <config:config-item config:name="KeepRatio" config:type="boolean">true</config:config-item> new entry (proposal): <config:config-item config:name="ExtraRowHeight" config:type="long">...</config:config-item> In this entry the extra row height could be saved and when the document is opened the entry could be read and the value could be loaded as extra height for calculating the Optimal row height. One remaining problem is that the Extra height value until now exists only once in LO and it is valid for all opened sheet documents. This should be changed.
I don't know the internals, but as "optimal width" and "optimal height" are "one-shot" operations (and not a formatting option) AFAIK, the cell widths and heights just need to be saved. And if there is a flag to auto-adjust the cell sizes: Clear such a flag. n my view the problem is that the new cell height (after optimizing) is not saved correctly, or not loaded correctly.
Dear Stefan_Lange_KA@T-Online.de, 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
The bug is still present in Version: 7.6.0.1 (X86_64) / LibreOffice Community Build ID: 776eaf34564cbf3f034a0ba1fd1d5c32ff9ccf1c CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded. But I think it is a fringe problem and the priority could be lowered to "minor".
I agree that this may be a fringe problem even though I personally have experienced it. The reason I agree it may be fringe is that—for me at least—the issue has always arisen deeper into the rabbit hole in attempts to solve the more common presenting issue that LibreOffice Calc does not reliably automatically adjust row height to fit the current length of all plain text wrapped cells on a row. Strangely, I cannot find a bug for the "automatic row height responsiveness to wrapped text length" bug. But I am searching.
IMHO the setting and use of optimal row height is a bit confusing: As found in the row styles in Context.xml the optimal row height is not used for a row when in the dialog an row height extra value > 0 is specified ("Default" is unchecked automatically), e.g.: <style:style style:name="ro3" style:family="table-row"><style:table-row-properties style:row-height="0.651cm" fo:break-before="auto" style:use-optimal-row-height="false"/></style:style> Tthe optimal row height is used only when in the dialog an extra value = 0 is specified ("Default" is checked). The row style is e.g.: <style:style style:name="ro1" style:family="table-row"><style:table-row-properties style:row-height="0.452cm" fo:break-before="auto" style:use-optimal-row-height="true"/></style:style> After I have found this I can live with. For me it is also OK that the row height extra value is kept for the use within the specific document where it is set. Because the used value is lost after the document (and LibreOffice) is closed and in order to avoid a different look of the rows after repeated changes of documents I use row height extra values only in exceptional cases. But I think it is not good that the row height extra value exists only once in LibreOffice for all opened sheet documents! IMHO a separate variable for the row height extra value (initial value : default) for every document would be better.