Problem description: Function "opimal Row Hight" doesn't work in spreadsheets created in previous versions of LO. Steps to reproduce: 1. Open a spreadsheet created in an older version of LibreOffice and containing a cell with several lines of text 2. Delete the whole content of the cell Current behavior: The row hight of this cell does not change automatically. Double clicking on the line between row numbers doesn't work either. The row hight can only be set manually. Expected behavior: The row hight of this cell should be reseted to default size. Double clicking on the line between the row numbers, or clicking on Format>Row>Optimal Hight should change the row hight to the optimal size. The problem does not affect spreadsheets created in current version(4.0)of LibreOffice Operating System: Ubuntu Version: 4.0.0.0.beta2 Last worked in: 3.6.4.3 release
Thanks for reporting! I can reproduce this behavior with LO master 4.1; Can't reproduce anymore with LO 3.6.4.3; Both tested with Ubuntu 12.10. I set this bug as 'NORMAL' and 'MEDIUM' because this doesn't resolve in instability/data loss/... but prevents you to make Professional High Quality work. (see flowchart https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg) Kind regards, Joren
joren@Ubuntu-Joren:~/bibisect40$ git bisect bad 6f692855bc8312410bc8a2257bcc298b34649955 is the first bad commit commit 6f692855bc8312410bc8a2257bcc298b34649955 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Mon Dec 10 00:13:53 2012 +0000 source-hash-d59024b652ccfaf7247da113ec36788fe260de74 commit d59024b652ccfaf7247da113ec36788fe260de74 Author: Michael Stahl <mstahl@redhat.com> AuthorDate: Thu Jul 12 22:18:43 2012 +0200 Commit: Michael Stahl <mstahl@redhat.com> CommitDate: Thu Jul 12 22:18:43 2012 +0200 warning C4101: unreferenced local variable Change-Id: I0648821a4d0c716371bb011df8cd9b21db79ccf5 :100644 100644 2e11de60e03551ff9cb9202630fabddffd9b4d03 13d66368624db1158439984d29b9b6b4e382edc1 M autogen.log :100644 100644 1aef3215ed700bc4e85fd12d18339c24ebf234a7 1c9624dd465ee0e59acd9c9dd05950b51be0c666 M ccache.log :100644 100644 f13bcc6696e46ed88900fa5b2390642319998036 b55a2bd9212e07b4042ebd0bb46515c8a4e76c04 M commitmsg :100644 100644 9d65d2f7c48177028e23641bc3eb0528844456f9 5270492409e164dc751ec11e4524f63b7739b35f M dev-install.log :100644 100644 9134f8edd2ee62e54d25821b3cc071e2aee24b5a f188090f0a4137ab411a3ff359ec440f0da4644c M make.log :040000 040000 e1e8f612101470e3ff2f6a53fc8c5e664103243f bb164bd44517d96b184ae0ecb1e8ccaf46ba0b4d M opt joren@Ubuntu-Joren:~/bibisect40$ git bisect log git bisect start # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect good 65fd30f5cb4cdd37995a33420ed8273c0a29bf00 # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 git bisect bad 5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a # good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9 # bad: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda git bisect bad f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a # good: [5bf3b624cdeb593e55402f44c730209f12813961] source-hash-4b4ca8030285bd66526ff5bb2b6ea5a75a6c6bc7 git bisect good 5bf3b624cdeb593e55402f44c730209f12813961 # bad: [70771b69f427dcd3ace8caea819338f104b88c43] source-hash-83837d6514217c82ebe8d56dddf89fa34f4b5435 git bisect bad 70771b69f427dcd3ace8caea819338f104b88c43 # bad: [517b06fcbaceee61aa0ce4cc51663cc835444966] source-hash-06f20d73da21342046a480a6b22af69901351328 git bisect bad 517b06fcbaceee61aa0ce4cc51663cc835444966 # bad: [e3fca4693fc359630ec1bbf45821875104da8928] source-hash-45c8db7ec89978029db2027585da986794971f7c git bisect bad e3fca4693fc359630ec1bbf45821875104da8928 # bad: [3501400226747f76691878608ef47b5148362858] source-hash-15af925c254f27046427de70a59011e2ac3d6bdb git bisect bad 3501400226747f76691878608ef47b5148362858 # bad: [6f692855bc8312410bc8a2257bcc298b34649955] source-hash-d59024b652ccfaf7247da113ec36788fe260de74 git bisect bad 6f692855bc8312410bc8a2257bcc298b34649955
(In reply to comment #1) > Thanks for reporting! > > I can reproduce this behavior with LO master 4.1; Can't reproduce anymore > with LO 3.6.4.3; Both tested with Ubuntu 12.10. > Yes. This bug affescts only LO 4.0 (or maybe 4.1 also) and only when you open a spreadsheet creates in an older version of LO.
@Daniel: Because of http://cgit.freedesktop.org/libreoffice/core/commit/?id=cd2f8a1cabbfb924c62d7af2aac3ac09288c2d4c I think you're the right person to 'ping'. Can you have a look at this bug please? Range: http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=4b4ca8030285bd66526ff5bb2b6ea5a75a6c6bc7..d59024b652ccfaf7247da113ec36788fe260de74
I suppose one for me.
Just to make it clear: This problem is not limited to files created with older versions. It is a general import problem because we are not handling the automatic row-height flag.
*** Bug 59579 has been marked as a duplicate of this bug. ***
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=62bf434229f9f86469dea3123bc6180bd9979c2c reset automatic row height flag after import, fdo#59193 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 59568 has been marked as a duplicate of this bug. ***
*** Bug 59023 has been marked as a duplicate of this bug. ***
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb40a72b5c811189ef783246c94a8ad226f7f347&h=libreoffice-4-0 reset automatic row height flag after import, fdo#59193 It will be available in LibreOffice 4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-4-0-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a6050279eb4e70cb82cfcae2e04b6fce07583149&h=libreoffice-4-0-0 reset automatic row height flag after import, fdo#59193 It will be available already in LibreOffice 4.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 59581 has been marked as a duplicate of this bug. ***
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d387140035547637338175ffdd22b5131a5e8f77 another row height ( related to optimalheight and deleting content ) fdo#59193 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 76340 [details] File containing two rows with style:use-optimal-row-height="true", first one (formatted in older version of LibO) keeps wrong height I'd like so see this bug report reopened - if I should file a new one, please let me know. In our hospital (and the 7 other hospitals in our hospital group) we use OOo/LO for several years to create PDF documents of our anesthesia documentation. We use a specially formatted CALC template with placeholders, fill it without user interaction with content and print to PDF. Since we updated from LibO 3.4.4 to 3.6.5 all rows using optimal row height are no longer formatted correctly. As we use the PDF as archive document in the digital patient data system, unreadable information is not tolerable - especially as we talk about 4.000 to 5.000 documents every month! Current behaviour: When opening an existing document (created with an older version of LibO) with line break in different cells, the row height is NOT adapted to the present content. Expected behaviour: Row height should be adapted to the content of cells. How to reproduce: Please open the attached file and look at row 3: the content is not visible, as the row height is not adapted. Even if you change the content or the font size, nothing happenes. In row 4 I clicked on the border to adapt auto row height again: Now the row height works as expected: change in content or font size leads to modified row heigth. In content.xml both rows are flagged with "style:use-optimal-row-height="true"", so I can't see the reason. Reproduced with LibO Version 3.6.2.2 (Build ID: da8c1e6) and LibO Version 4.0.1.2 (Build ID: 84102822e3d61eb989ddd325abf1ac077904985) on Win XP. Thanks for consideration - it's important for 8 hospitals and a great number of documents. Bernhard (former bedipp at LibO and OOo)
added myself to CC, as this seems not to be possible when adding an attachment
(In reply to comment #16) I believe this on was concerning a different problem, for some documents from oder LibO versions AFTER "import" (opened with current version) it was completely impossible to do adapt row hight correctly and edits in the cells left hidden text. I do not see these problems with 4.0 in my documents, but did not check systematically. Your problem seems to be that you expect that LibO does an auto row height calculation WHILE you open the document (I do not know, do we promise that?), what might be something different. So I recommend a new bug report.
Thanks, Rainer! I reported bug 62268, as you suggested.
Removing comma from Whiteboard (please use a space to delimit values in this field) https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started [NinjaEdit]