https://bugs.freedesktop.org/show_bug.cgi?id=62268
Rainer Bielefeld <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEEDINFO CC| |LibreOffice@bielefeldundbus | |s.de Summary|FORMATTING: automatic row |FORMATTING: Optimum row |height is not recalculated |height should be retained |on FILEOPEN (regression) |after save - close - reopen Ever confirmed|0 |1 --- Comment #2 from Rainer Bielefeld <[email protected]> --- To avoid misunderstanding: I do not think that we promise somewhere that there will be automatic row height adaption when a file is opened I would dislike such a function. What if I intendedly wanted to "hide" some text? When I open a document I want to see the same row height I saw when I saved the document. And that seems more or less what reporter expects. To get familiar with the current situation I did some tests (what might not all be related to core of the problem). Due to <http://odf-validator2.rhcloud.com/odf-validator2/> reporter's sample document is valid ODF I opened reporter's sample with various different LibO Versions (all: WIN7, 64 Bit), checked row heights for rows, tested result (problem healed?) after a: for A4:A5 Format --> Rows -> Optimimum height' b: Insert <Space>, then <Enter> at end of cell text c: Result (text vies A5) when reopen documents after test 'b' (problem with version from ....) 3.3.3 row 4: 51,8 mm, not all text visible, a: yes, b: yes row 5: 07,6 mm, all text visible, c: 3.3.3=cut top/bottom 3.4.5=cut top/bottom 3.5.7.2=cut top/bottom 4.0.1.2=cut top/bottom, Master=cut top/bottom AOO=cut top/bottom Symph=cut top/bottom 3.4.5 row 4: 51,8 mm, not all text visible, a: yes, b: yes row 5: 07,6 mm, all text visible, c: Same as with 3.3.3 3.5.7.2 row 4: 04,8 mm, not all text visible, a: yes, b: yes row 5: 07,9 mm, all text visible, c: All correct opened 3.6.5.2 row 4: 04,8 mm, not all text visible, a: yes, b: yes row 5: 07,9 mm, all text visible, c: All correct opened 4.0.1.2 row 4: 04,8 mm, not all text visible, a: yes, b: yes row 5: 07,9 mm, all text visible, c: All correct opened 4.1.0.0+ Master row 4: 04,8 mm, not all text visible, a: yes, b: yes row 5: 07,9 mm, all text visible, c: All correct opened AOOo 3.4.1 row 4: 54,8 mm, all text visible, row 5: 07,2 mm, all text visible, c: not tested Symphony row 4: 51,4 mm, all text visible, not all text visible, a: yes, b: yes row 5: 07,2 mm, all text visible, c: not tested After all these results I would like a more precise Bug Summary: Optimum row height should be retained after save - close - reopen. For this bug definitions after LibO 3.4 no longer any problems So I see this problem WFM. @Bernhard Dippold first: I can not reproduce your results. Only AOOo opens your sample with optimum row height. All LibO versions cut contents. I think your problem is different to the one you stated in the summary line. It seems you expect that due to "style:use-optimal-row-height='true' the row height should be recalculated when you open the file. But that might be wrong. I cite ISO/IEC 26300 First edition 2006-12-01: 15.10.2 Optimal Table Row Height The style:use-optimal-row-height attribute specifies that the row height should be recalculated automatically if some content in the row changes. Or Open Document Format for Office Applications (OpenDocument) Version 1.2 Part 1: OpenDocument Schema OASIS Standard 29 September 2011: 20.384 style:use-optimal-row-height The style:use-optimal-row-height attribute specifies that a row height should be recalculated automatically if content in the row changes. The defined values for the style:use-optimal-row-height attribute are: ● false: row height should not be recalculated automatically if content in the row changes. ● true: row height should be recalculated automatically if content in the row changes. This is something like my test 'B' and works for all LibO Versions. But you can't expect a recalculation at fileopen, your software manipulating contents will be responsible for height recalculation. May be you benefitted from some liberal interpretation of ISO or similar? Can you explain the different observations? I see text in A5 truncated also with 3.4.5., can it be that 3.4.4 behavior differs? I will check later. Currently I see no bug here. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
