Bug 59193 - automatic row height does not work after import
Summary: automatic row height does not work after import
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.0.0.0.beta2
Hardware: Other Linux (All)
: medium normal
Assignee: Markus Mohrhard
URL:
Whiteboard: BSA bibisected40 target:4.1.0 target:...
Keywords: regression
: 59023 59568 59579 59581 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-01-10 10:56 UTC by Przemyslaw Kaplon
Modified: 2018-06-12 08:26 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
File containing two rows with style:use-optimal-row-height="true", first one (formatted in older version of LibO) keeps wrong height (12.83 KB, application/vnd.oasis.opendocument.spreadsheet-template)
2013-03-11 15:04 UTC, Bernhard Dippold
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Przemyslaw Kaplon 2013-01-10 10:56:37 UTC
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
Comment 1 Jorendc 2013-01-10 12:41:13 UTC
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
Comment 2 Jorendc 2013-01-10 12:49:08 UTC
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
Comment 3 Przemyslaw Kaplon 2013-01-10 16:17:45 UTC
(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.
Comment 5 Markus Mohrhard 2013-01-19 17:28:13 UTC
I suppose one for me.
Comment 6 Markus Mohrhard 2013-01-19 18:37:03 UTC
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.
Comment 7 Jorendc 2013-01-19 23:44:57 UTC
*** Bug 59579 has been marked as a duplicate of this bug. ***
Comment 8 Not Assigned 2013-01-22 22:53:11 UTC
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.
Comment 9 Markus Mohrhard 2013-01-23 10:47:06 UTC
*** Bug 59568 has been marked as a duplicate of this bug. ***
Comment 10 Petr Mladek 2013-01-23 17:12:24 UTC
*** Bug 59023 has been marked as a duplicate of this bug. ***
Comment 11 Not Assigned 2013-01-24 10:08:24 UTC
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.
Comment 12 Not Assigned 2013-01-24 15:23:58 UTC
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.
Comment 13 Markus Mohrhard 2013-01-24 19:06:05 UTC
*** Bug 59581 has been marked as a duplicate of this bug. ***
Comment 14 Not Assigned 2013-02-07 11:36:28 UTC
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.
Comment 15 Bernhard Dippold 2013-03-11 15:04:07 UTC
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)
Comment 16 Bernhard Dippold 2013-03-11 15:05:22 UTC
added myself to CC, as this seems not to be possible when adding an attachment
Comment 17 Rainer Bielefeld Retired 2013-03-11 16:19:05 UTC
(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.
Comment 18 Bernhard Dippold 2013-03-13 00:04:34 UTC
Thanks, Rainer!

I reported bug 62268, as you suggested.
Comment 19 Robinson Tryon (qubit) 2015-12-22 01:31:10 UTC
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]