Bug 84670 - Conditional formatting changes row height
Summary: Conditional formatting changes row height
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.1.6.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Conditional-Formatting
  Show dependency tree / graph
 
Reported: 2014-10-04 19:11 UTC by rlk
Modified: 2024-03-21 12:44 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Attachments
Test case (597.47 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-10-06 00:39 UTC, rlk 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description rlk 2014-10-04 19:11:21 UTC 
Applying conditional formatting changes the row height (specifically, adds some margin to the top of the cell).

My default style is defined as

Liberation Sans Narrow + 8pt + Automatic + Centered vertically + Automatic + FALSE + TRUE + Left margin: 0.03inch, Top margin: 0.0inch, Right margin: 0.03inch, Bottom margin: 0.0inch + White, Transparent.

I have defined a style named Challenge which is linked with Default and defined as

8pt + Left margin: 0.03inch, Top margin: 0.0inch, Right margin: 0.03inch, Bbottom margin: 0.0inch + RGB(191, 152, 229), Not Transparent

If I apply conditional formatting to a range of cells, where a cell that passes the conditional formula is set to style Challenge, all of the rows with cells in that range get an extra pixel or two of top margin above the text (regardless off what condition applies within the cells).

If I apply the formatting manually, or by use of STYLE() within formulas, this doesn't happen: the cells retain their correct height and margin.

I've observed this before with different style settings.
Comment 1 rlk 2014-10-04 20:56:25 UTC 
Still present in 4.3.2.2.
Comment 2 rlk 2014-10-05 23:28:18 UTC 
I can change the row height back to 0.1" (from the 0.11" it was changed to) manually.  However, as soon as I enter something into one of the cells covered by the conditional formatting, the row height goes back to 0.11".
Comment 3 m_a_riosv 2014-10-05 23:43:03 UTC 
Hello rlk@alum.mit.edu,

Thank you for reporting the bug. Please attach a sample document, as this makes it easier verify the bug. 
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Comment 4 rlk 2014-10-06 00:39:02 UTC 
Created attachment 107385 [details]
Test case

Enter 10000 into a1626, and watch the row height increase from 0.1 to 0.11"
Comment 5 ign_christian 2014-10-06 04:05:40 UTC 
Maybe related to Bug 34552, especially https://bugs.freedesktop.org/show_bug.cgi?id=65837#c11 which shows problem with LO import / file load changing row height.

Attached file shows -almost- correct height while opened with AOO 4.1.1 portable under Win7 x86. Row height comparison (with AOO 4.1.1):
- initial height of cell A1626 : 0.28 cm
- after doing comment 4 : 0.29 cm (same with other cells processed by CF before eg. cell A1625)

With LO 4.3.2.2 portable and 4.0.6.2, initial height of cell A1626 is 0.25 cm.
Comment 6 rlk 2014-10-06 12:35:44 UTC 
The symptoms don't sound like it.  The issue does not appear related to load or import; it's specifically related to conditional formatting (if I apply the same style via the style menu/F11 or with STYLE() the row height is correct).
Comment 7 raal 2014-10-19 06:48:53 UTC 
Hello,
I think conditional formatting is not applied. Condition is AND(N($D1626)>0;MONTH(N($D1626))=3), for value 10000 this condition is FALSE. Parts of condition N($D1626)>0 is TRUE , MONTH(N($D1626))=3 is FALSE. Function AND returns TRUE if all arguments are true.
Tested with LO Version: 4.4.0.0.alpha0+, height 0,25cm changed to 0,45cm (default value).
Comment 8 rlk 2014-10-19 14:54:43 UTC 
Correct, but conditional formatting applies to the cell range.  Entering something into a cell in the range results in the height changing, whether or not the condition is triggered.
Comment 9 raal 2014-10-20 09:56:10 UTC 
I can confirm with LO  4.3.2, WIN7.When I delete condition then bug doesn't occurs.
Comment 10 rlk 2014-11-01 15:54:54 UTC 
Workaround: if I _manually_ set the row height to 0.1" (as opposed to Optimal Row Height), it stays at 0.1".
Comment 11 QA Administrators 2015-12-20 16:08:40 UTC Comment hidden (obsolete)
Comment 12 rlk 2015-12-25 23:54:18 UTC 
I'm still observing that when I enter something into A1626 that its height changes, but in this case from 0.1 to 0.11 inch.  This may be due to bugs 77592 and/or 83568, so I cannot say thatt this bug is either fixed or not.
Comment 13 rlk 2015-12-26 01:22:21 UTC 
Comment 12 is wrong: it changes from 0.1 to 0.18 because of the two other bugs listed.

Can't meaningfully test in 5.1RC either because of said other bugs blocking this.
Comment 14 QA Administrators 2017-01-03 19:55:24 UTC Comment hidden (obsolete)
Comment 15 rlk 2017-01-03 20:10:14 UTC 
Can't meaningfully test in 5.2.3.3 (on Linux openSUSE RPMs).  See comment 13 for explanation; it's blocked by other bugs.
Comment 16 QA Administrators 2018-01-16 03:29:04 UTC Comment hidden (obsolete)
Comment 17 Xavier Van Wijmeersch 2018-01-16 16:08:16 UTC 
Opening the test case with LO 5.3.2.1 its crashing LO and with 6.1.0.0 master there is a core dump

Version: 5.3.1.2
Build ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2
CPU Threads: 8; OS Version: Linux 4.14; UI Render: default; VCL: kde4; Layout Engine: new; 
Locale: nl-BE (en_US.UTF-8); Calc: group

Version: 6.1.0.0.alpha0+
Build ID: fa014ee6e13d182cb5830698558284e7caffa5f9
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group threaded
Comment 18 QA Administrators 2019-07-09 02:44:08 UTC Comment hidden (obsolete)
Comment 19 rlk 2019-07-13 15:17:48 UTC 
Can't meaningfully test in 6.2.5.2, because of reasons noted in comment #13.
Comment 20 QA Administrators 2021-07-13 03:39:48 UTC Comment hidden (obsolete)
Comment 21 QA Administrators 2023-07-14 03:14:14 UTC Comment hidden (obsolete, spam)
Comment 22 Justin L 2024-03-21 12:44:06 UTC 
I would assume this is just a duplicate of bug 83568. Any change made will invoke a "minimum height".