Created attachment 76545 [details] Test Kit for easy reproducing Step 20 I found this one during my tests for "Bug 62268 - FILEOPEN: Optimum row height should be recalculated with "style:use-optimal-row-height='true'"". The core of the problem is that for an existing document (created with 3.3.3) the row height will not be calculated. I think that a lot of aspects might have influence whether row height should be adapted. So I contribute all steps including creation of the sample document. Steps with Server Installation of "LibreOffice 3.3.3 English UI/ German Locale [OOO330m19 (Build:301) tag libreoffice-3.3.3.1] on German WIN7 Home Premium (64bit) (creating sample document) 1. New spreadsheet from LibO Start Center 2. On Sheet2 Cell A1 Type "This is a pretty long text " 3. Increase column A width dragging border between Column headings A-B to app. double size (so that it's a little more than text length) 4. A2: "=A1" 5. fill A2 to A3 .... A20 > All cells A1:A20 show same text as A1 6. Sheet1.A1: "=CONCATENATE(Sheet2.A1;Sheet2.A2;Sheet2.A3;Sheet2.A4;Sheet2.A5; Sheet2.A6;Sheet2.A7;Sheet2.A8;Sheet2.A9;Sheet2.A10)" > Shows long text in Sheet1.A1 exceeding Cell size 7. Menu 'Format -> Cells -> Alignment -> Wrap Text Automatically' <ok> > Text wrapped into cell with increased row height (20 text lines or so). 8. Save document as "sample_333_01.ods", close, reopen > Still shows text wrapped correctly in Sheet1.A1 9. Double click Sheet2.A1 (Cel Edig mode) 10. <control+a> to select all cell contents 11. <control+c> to copy all cell contents 12. click into cell behind trailing blank > caret flashes behind text 13. <control+c> to copy text > Text now with double length in All cells 14. Check Sheet1.A1 Row height has NOT been increased (I haven't a clue whether that is intended or not) 15. Save document as "sample_333_02.ods", close, 16. reopen "sample_333_02.ods: Now row height HAS been increased, showing approximately 40 text lines in cell for all text 17. Close document without saving 20. Now tests with other versions: Do only Step 16, until 3.5.6 always will show increased row height for Sheet1.A1 showing app. 40 text lines with all text. Still [Reproducible] with parallel Dev-installation of "Version 4.1.0.0.alpha0+ (Build ID: 61add5c77de1ff963b839020c77f67f14ef07de) TinderBox: Win-x86@6, Branch:master, Pull Time: 2013-03-05_00:20:08" ENGLISH UI / German Locale on German WIN7 Home Premium (64bit) with LODev/4 Masters User Profile Bug: ---- Starting with server installation of "LibreOffice 3.5.7.2 German UI/Locale [Build-ID: 3215f89-f603614-ab984f2-7348103-1225a5b] on German WIN7 Home Premium (64bit) you will only see the 20 text lines as in step 14, text is truncated in Sheet1.A1. I believe that this is at least a part of the problem in Bug 62268, But because there might be involved various effects I decided to submit a separate bug. @Bernhard Dippold: I believe this test kit reproduces more or less your problem, what do you think? Can you reproduce my observations?
Seems Bernhard Dippold is not interested in confirming? So I turn it to NEW without review. @Spreadsheet Team Please add Whiteboard tag "bibisectrequest" if you think that a bibisect result can ease your work. Please change Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf (and remove others in team from CC).
Sorry Rainer - I had too much other work to do this week :-( I got access to a Windows XP computer with LibO 3.4.3 (OOO340m1, build 302) installed. With this version your first sample in the testkit (sample_333_01.ods) opens with a height of 8,90 cm for row 1, while the second saple (sample_333_02.ods) opens with 17,29 cm in height. With LibO 4.0.0.3 on WinXP the row height in sample_333_01.ods is 8,58 cm, in sample_333_02.ods it's 8,58 cm, too. In both files content.xml shows the defined height for the style used for the first row in sheet 1 (in sample_333_01.ods this style is called "ro1", in sample _333_02.ods the style is "ro2") as "8.585cm". Bot styles use 'style:use-optimal-row-height="true"'. So yes, I can confirm the bug: Former versions recalculate row height on fileopen, when style:use-optimal-row-height="true", newer versions just use the defined row height without recalculation. In my eyes this is a REGRESSION, that might be related to quite a number of row height bugs (especially with imported files, as it is very likely that they need a recalculation on fileopen). But as the necessity to recalculate row height on fileopen seems not to be defined in the OASIS ODF definition (as we mentioned in bug 62268), I don't add this keyword. Please feel free to do so, if you agree with me.
After more than half a year without reply by any of the developers asked for comments by Rainer Bielefeld the related bug 62268 has been commented by another user confirming the bug of FILEOPEN without regarding the "use optimal row height" flag being still present in an actual LibO version. At our hospital group we still use LibO 3.5.5 on servers in 9 hospitals just because of this bug. I didn't add the REGRESSION keyword as mentioned in my last comment, because I don't know if recalculation on fileopen is part of the OASIS ODF definition. In bug 62268 Bernhard Donaubauer comments that at least OOo "always stated that the creation of ODF via XML, XSLT, ... is a valid way to generate ODF Files." If this is still valid, this bug is a regression! Is anybody able to have a look? Would it be reasonable to define one of the bugs as duplicate to the other one?
I searched for related bugs and found a few that might be worth to be looked at by a developer starting to work on this (bug 69745 should be added to the related bugs list or marked as duplicate to this one, perhaps bug 55433, bug 63122 or bug 68375 could be fixed too by a possible patch). Noel Powers provided a patch to bug 49255 (preserving row height on save and open), implemented in LibO 3.5.7. As this bug here (and in bug 62268) was first mentioned in that version, I added him to CC: Is it possible, that your patch caused ignorance to 'style:use-optimal-row-height="true"' on FILEOPEN? Do you know any other patch in this version related to this topic? Best regards Bernhard (not being a developer I can't find out more by myself)
It would be nice if a LO developer could comment on this topic.
Update: Tested with LibO 4.3.0.2 and LibO-Dev 4.3.1.0.0+ (2014-07-14_09:38:08) on Win 8.1 Sorry for a longer description, but for a decision, if this bug should be closed, you need some more information: Step 14. results in increased row height, so re-building of the sample documents is no longer possible. But if you open the sample document "sample_333_02.ods" from the attached Test Kit, you still experience the reduced row height: Instead of 41 lines in cell A1 on Sheet1 the cell is cut at 21 lines, according to the content.xls it's about 8,6 cm height: <style:style style:name="ro2" style:family="table-row"> <style:table-row-properties style:row-height="8.585cm" fo:break-before="auto" style:use-optimal-row-height="true" /> </style:style> So LibO uses the row-height defined in the file, but ignores the flag "style:use-optimal-row-height='true'" in the UI. As cell A1 on Sheet1 is selected you can find the height of row 1 just in the menu: 'Format -> Row -> Heigth' described as 16,64 cm. If you click anywhere in the file (except the LibO menu) the cell is expanded, but the row indices at the left border keep the wrong height. Only if you force expicitly a recalculation of the screen (by "OK" on row height in the menu, moving the focus out of the visible screen modifying zoom factor or anythign like this) you get the right height including the indices. Even if you save the document and reopen it, you will get the right row height, as it saves the value style:row-height="16.639cm" in content.xml. So the bug seems to be still valid - as the behavior in the description "FILEOPEN without optimum row height calculation" is still the same, if you look at the UI. In the background recalculation seems to be done nevertheless (as to be seen on the menu entry "Format - Row - Height") - so the resulting bug is only a UI refresh bug, no more recalculation. Should we close this one and open a new bug for this behavior? Best regards Bernhard
(In reply to comment #6) > Update: > Tested with LibO 4.3.0.2 and LibO-Dev 4.3.1.0.0+ (2014-07-14_09:38:08) on > Win 8.1 > Step 14. results in increased row height, so re-building of the sample > documents is no longer possible. > > But if you open the sample document "sample_333_02.ods" from the attached > Test Kit, you still experience the reduced row height: > ... > If you click anywhere in the file (except the LibO menu) the cell is > expanded, but the row indices at the left border keep the wrong height. > ... > Even if you save the document and reopen it, you will get the right row > height, as it saves the value style:row-height="16.639cm" in content.xml. This behaviour also confirmed under GNU/Linux x86_64 using v4.2.5.2. Platform set to All/All.
** 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
Bug is still present in 5.3.0.3, check this: bug 62268
Bug is still present in 5.3.2.2. Pleas a coder should check the new argument there: bug 62268
Here a link where i assume the bug. Check: getRowPropertiesMap -> OptimalHeight, OptimalWidth https://docs.libreoffice.org/xmloff/html/XMLTableExport_8cxx_source.html#l00081
** 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
Please test with master and write some simple test steps.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20190111
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20190321