[Libreoffice-bugs] [Bug 142893] New: Issues with row height calculation

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=142893

            Bug ID: 142893
           Summary: Issues with row height calculation
           Product: LibreOffice
           Version: 7.0.5.2 release
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Calc
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: michael at vonglasow.com

Calc has a few issues with row height calculation, which are somewhat
interrelated.

To reproduce:

1. Open a blank spreadsheet.
2. Format cells A1:B4 to auto-wrap text.
3. Fill cells B1:B4 with text, about 6 rows per cell.
4. Apply optimum row height if necessary.
5. Zoom in (about 140%).
6. Verify row height, and apply optimum row height again.
7. Zoom back to 100%.
8. Verify row height, and apply optimum row height again.
9. Fill A1 with long text (longer than B1:B4 combined).
10. Merge A1:A4, apply optimum row height if necessary.

Expected behavior:

* Zooming in and out should not affect row height calculation, i.e. steps 6 and
8 should not result in row height changes.
* Editing text should not affect row height changes, unless the cell being
edited is the single tallest cell in its row either before or after editing.
* If a merged cell needs to be taller than the sum of its constituent rows, the
rows should be enlarged (e.g proportionally).

Actual behavior:

* When zooming in or out, text may suddenly become too long for the cell to
accommodate.
* When editing text in a row, even a one-liner next to a cell containing
multiple rows (previously set to optimum height), the row may shrink slightly,
causing the long text to no longer fit.
* Merged cells are as tall as their constituent rows, never taller, even if
their content does not fit.

Additional comments:

* Size calculations should be done in a display-neutral manner; same goes for
the actual layout. This is also occasionally an issue with printing: text fits
into one row on screen but is wrapped in the printout due to minute differences
in layout and text length being close to one full row.
* It looks as if the code has two different routines for row height calculation
in different places, with different results. Code deduplication would probably
solve that.
* Merged cell height is probably a tricky issue, with multiple possible
solutions. If nothing else works, extend the last row of the merged cell so the
content fits. Proportionally enlarging cells would give nicer results, but may
become difficult if different merged cells span overlapping ranges of rows
(say, A1:A2 and B2:B3).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210616/ef543cce/attachment-0001.htm>