Created attachment 136373 [details] Screenshot with test for inter-line spacing of multiline text in Calc Caolán's work on bug 107249 also has fixed bug 108891 for few-line text in cells. (Thanks for that!) But the more lines you have the more you can see that the calculation of inter-line spacing for multiline text needs further improvements. In the attached screenshot I've compared 9 rows with increasing lines per cell (row 1 with 1 line, row 2 with 2 lines, etc.) in * MSO Excel 2013 * LibO 3.3.0.4 * LibO 5.1.6.2 * LibO 5.4.2.1 You can see that the row height is more like the Excel template in LibO 5.x - but the inter-line spacing for multiline text get worse between 3.3 and 5.1 and more worse with 5.3/5.4/6.0.
Created attachment 136374 [details] xlsx test file for inter-line spacing of multiline text
Created attachment 136376 [details] Same sequenced multi line text in a flat ODF Actually, I think the oox excel import filter gets in the way here. Imported text is vertically formatted to bottom of cell. And if I flush the Cell formatting through Vertical -> Distributed it cleans up fine. So, rather than an import from OOXML, attached is the text as native .fods from a 5.4.1.2. On creating it receives default horizontal and vertical cell formatting, and displays no inter-line spacing issues. Working on Widnows 10 Ent 64-bit en-US with Version: 5.4.1.2 (x64) Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527 CPU threads: 8; OS: Windows 6.19; UI render: GL; Locale: en-US (en_US); Calc: group
Created attachment 136377 [details] greater font leading required redistribution in 5.4.2.1 Interesting, with 5.4.2.1 the now recalculated Font leading required a "redistribution" of the .fods file cells to hold the corrected line spacing. Was thrown at first with the cells no longer holding text of the original .fods Guess it makes sense the corrected leading would need greater per row height, but weird that the ODF use-optimal-height would not force it to recalculate on filter import.
Created attachment 136394 [details] screenshot of spreadsheet created with 5.4.2.1, opened also in 5.1.6.2 and 3.3.0.4 I see no difference in line spacing whether it's imported from another file format (as seen in my first attachment) or it's a native LibO file. The attached screenshot shows a spreadsheet created with 5.4.2.1, opened in 5.4.2.1 (right), 5.1.6.2 (center) and 3.3.0.4 (left). You can see that there is much difference in line spacing and that it has became worse after the 3.x series and additionally worse with the 5.3 series. Version: 5.4.2.1 (x64) Build-ID: dfa67a98bede79c671438308dc9036d50465d2cb CPU-Threads: 8; Betriebssystem:Windows 6.19; UI-Render: Standard; Gebietsschema: de-AT (de_DE); Calc: group Version: 5.1.6.2 (x64) Build-ID: 07ac168c60a517dba0f0d7bc7540f5afa45f0909 CPU-Threads: 8; BS-Version: Windows 6.19; UI-Render: Standard; Gebietsschema: de-AT (de_DE); Calc: group LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Created attachment 136395 [details] ods spreadsheet created with 5.4.2.1 (used for the screenshots) I inserted the content without formatting and didn't change anything in cell formatting.
(In reply to Thomas Lendo from comment #4) > Created attachment 136394 [details] No that is a correct interpretation. At 5.4.2.1 with "new" leading, the table for the sheet receives row sizing appropriate to that leading. When you move that table back to 5.1.6.2 or 3.3.0.4 the table is opened with that row size--but the per line font leading is as defined at that build. You would have to redistribute to get a new row size based on the font leading.
(In reply to V Stuart Foote from comment #6) s/is a correct interpretation/is an incorrect interpretation/
Created attachment 136422 [details] Test files created with 3.3 + 5.1 + 5.4 (each as png + ods) (In reply to V Stuart Foote from comment #6) > When you move that table back to 5.1.6.2 or 3.3.0.4 the table is opened with > that row size--but the per line font leading is as defined at that build. Opened in 5.1.6.2, the row size is identical to what was defined in 5.4.2.1. (Rows 1-11 have the same height in all 5.x versions.) LibO 3.3 acts differently by doing an adjustment of the row height. (All rows are higher than in later versions.) I assume this is an intended behavior--the rows should be fixed to keep the layout as it is. But that is not what I had in mind when creating this bug report. Adjusting the row size is done easily. To clarify what was my intention with this bug report: Multiline text looks compact, crowded together, not good-looking in current versions at least since 5.3. The patch made it better but there is room for enhancement. I know the above-noted attributes are subjective and I know the opinion of other people that a spreadsheet shouldn't be used for text. But people are using software as they want and what's possible and not as it was intended or thought originally. If you forget that all and take only a look at the screenshots with the 3 LibO columns (attached in this zip archive), which version is looking best and easily readable? Personally, older versions of LibO made a good job in presenting multiline text. That's similar how the competitive software acts. Therefore I suggest to further increase the inter-line spacing for the sake of interoperability and readability and to have sexy spreadsheets. At least until there is a patch for bug 108555. I created a test file with the three LibO versions mentioned above and opened it in the other two version. I compared all 3 files with all 3 LibO versions. In all three test files, LibO 5.4.x made the worst job, subjectively spoken.
Created attachment 136425 [details] screenshot of spreadsheet created with 5.1.6.2, opened also in 5.4.2.1 and 3.3.0.4 Although the attached screenshot is part of attachment 136422 [details], to show the difference in line-spacing in a spreadsheet created with 5.1.6.2.
Don't see an issue here that needs attention other than what is required for bug 108555. Resolved DUPLICATE. Calculation of line heights for wrapped text in a table cell (the object in calc sheet and writer tables) is now picking the consistently "correct" line height based on internal leading of the font [1][2]. This is the same value of single line or %100 height of a paragraph object created with the font. IIUC it is also the value used in calc when vertical distribution is applied to reformat the cell(s). So with line wrap on and use-optimized the table cell gets vertical size for a line spacing at 100% of its calculated font height. That is now consistent cross platform. And that closed bug 108891. Adding any more interline spacing requires use of a multiplier for the line spacing, either fixed or user set proportional--that is bug 108555. And this should be duplicated to that. =-ref-= [1] Khaled's work on bug 55469 https://cgit.freedesktop.org/libreoffice/core/commit/?id=34d7602954d4483b3bc9db700e7df2c15348947a [2] Caolan's correction of rounding errors in leading. https://cgit.freedesktop.org/libreoffice/core/commit/?id=0c8b749e602b6743857a9bc4efb24b6183690311 *** This bug has been marked as a duplicate of bug 108891 ***
lets make that the correct duplicate of bug 108555. *** This bug has been marked as a duplicate of bug 108555 ***