Created attachment 60739 [details] file saved Problem description: row height not preserved after saving and and loading Steps to reproduce: 1. Open the attachment. 2. Click on the border between row 2 and row 3 to automatically adjust the row height. 3. Save this file. 4. Open it again. Current behavior: Row height of row 2 is too short. Expected behavior: Row height of row 2 should display all text. Platform (if different from the browser): Browser: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 Windows NT 6.1 means Windows 7. Language of Windows and LibreOffice: Chinese (complex, also called traditional)
This may be a duplicate of: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=40645 But note that OpenOffice 3.3 is correct. This forces me to go back to OpenOffice 3.3. Thanks.
Please do not use https://www.libreoffice.org/bugzilla/*, use https://bugs.freedesktop.org/* URLs instead.. Thanks Florian R.
Dear Florian, I just followed the "bugs" link on the LibreOffice home page. Thanks. Qiyao ________________________________ 寄件者： "bugzilla-daemon@freedesktop.org" <bugzilla-daemon@freedesktop.org> 收件者： lotus7174@kimo.com 寄件日期： 2012/5/20 (週日) 1:42 AM 主旨： [Bug 49255] FORMATTING: Calc: row height not preserved after saving and and loading https://bugs.freedesktop.org/show_bug.cgi?id=49255 --- Comment #2 from Florian Reisinger <reisi007@gmail.com> 2012-05-19 10:42:10 PDT --- Please do not use https://www.libreoffice.org/bugzilla/*, use https://bugs.freedesktop.org/* URLs instead.. Thanks Florian R.
NOT reproducible with "LibreOffice 3.5.5.3. German UI/Locale [Build-ID: 7122e39-92ed229-498d286-15e43b4-d70da21] on German WIN7 Home Premium (64bit) I do not know how to "Click on the border between row 2 and row 3 to automatically adjust the row" @Zhong Qiyao Thank you for your report – unfortunately important information is missing. May be hints on <http://wiki.documentfoundation.org/BugReport> will help you to find out what information will be useful to reproduce your problem? If you believe that that is really sophisticated please as for Help on a user mailing list Please: - Write a meaningful Summary describing exactly what the problem is – if possible contribute an instruction how to create a sample document from the scratch - Contribute a document related step by step instruction containing every key press and every mouse click how to reproduce your problem (similar to example in Bug 43431) - add information -- what EXACTLY is unexpected (old row height, new row height can you observe problem also when reopen with other versions) -- and WHY do you believe it's unexpected (cite Help or Documentation!) -- concerning your PC -- concerning your OS (Version, Distribution, Language) -- concerning your LibO version (with Build ID if it's not a public release) and localization (UI language, Locale setting) –- Libo settings that might be related to your problems -- how you launch LibO and how you opened the sample document –- If you can contribute an AOOo Issue that might be useful -- everything else crossing your mind after you read linked texts Concerning your uncertainty how to refer to an other Bug: <https://wiki.documentfoundation.org/QA-FAQ#How_to_use_attached_sample_documents_for_multiple_Bug_Reports>
This still happens in LibreOffice 3.6RC2 Chinese (trad.) running on Chinese (trad.) Windows XP, with cell content in Arial font. << I do not know how to "Click on the border between row 2 and row 3 to automatically adjust the row" >> I mean "on the leftmost column, where you have row numbers, double-click on the border between row 2 and row 3". This will automatically adjust the row height. Thanks. ________________________________ 寄件者： "bugzilla-daemon@freedesktop.org" <bugzilla-daemon@freedesktop.org> 收件者： lotus7174@kimo.com 寄件日期： 2012/7/24 (週二) 11:58 PM 主旨： [Bug 49255] FORMATTING: row height not preserved after FILESAVE and reopen https://bugs.freedesktop.org/show_bug.cgi?id=49255 Rainer Bielefeld < changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEEDINFO CC| |LibreOffice@bielefeldundbus | |s.de Ever Confirmed|0 |1 Summary|FORMATTING: Calc: row |FORMATTING: row height not |height not preserved after |preserved after FILESAVE |saving and and loading |and reopen --- Comment #4 from Rainer Bielefeld <LibreOffice@bielefeldundbuss.de> 2012-07-24 08:58:48 PDT --- NOT reproducible with "LibreOffice 3.5.5.3. German UI/Locale [Build-ID: 7122e39-92ed229-498d286-15e43b4-d70da21] on German WIN7 Home Premium (64bit) I do not know how to "Click on the border between row 2 and row 3 to automatically adjust the row" @Zhong Qiyao Thank you for your report – unfortunately important information is missing. May be hints on <http://wiki.documentfoundation.org/BugReport> will help you to find out what information will be useful to reproduce your problem? If you believe that that is really sophisticated please as for Help on a user mailing list Please: - Write a meaningful Summary describing exactly what the problem is – if possible contribute an instruction how to create a sample document from the scratch - Contribute a document related step by step instruction containing every key press and every mouse click how to reproduce your problem (similar to example in Bug 43431) - add information -- what EXACTLY is unexpected (old row height, new row height can you observe problem also when reopen with other versions) -- and WHY do you believe it's unexpected (cite Help or Documentation!) -- concerning your PC -- concerning your OS (Version, Distribution, Language) -- concerning your LibO version (with Build ID if it's not a public release) and localization (UI language, Locale setting) –- Libo settings that might be related to your problems -- how you launch LibO and how you opened the sample document –- If you can contribute an AOOo Issue that might be useful -- everything else crossing your mind after you read linked texts Concerning your uncertainty how to refer to an other Bug: <https://wiki.documentfoundation.org/QA-FAQ#How_to_use_attached_sample_documents_for_multiple_Bug_Reports>
This also happens in 3.6 RC 2, and Apache OpenOffice 3.4. By step 2 "clicking on the border", I mean double-clicking on the row border at the heading (leftmost) column. You can also use the function "row height > automatic" to achieve the same problem. But if this is a manually adjusted row height, or an automatic row height "plus 0.5", and saved, then this problem does not happen. By comparing with OpenOffice 3.3, where this problem did not happen, it was observed that the cells in LibrO were opened with more or less the same size, but character size (in this case Arial) inside those cells are "wider", thus wrapping into one more line, needing one more text line in the cell than OpenOffice 3.3. But when this file is now saved in LibreOffice 3.6 RC 2 and opened, the cell went back to its original height, which is the "enough" height for OpenOffice 3.3, but "too short" for LibreOffice 3.6 RC 2. Thanks.
The new attachment (test.ods) was created from scratch: 1. Windows XP, Chinese (trad.). 2. LibreOffice 3.6 RC 2. 3. Open blank Calc document. 4. Type into B2, "aaa bbb ccc ddd". 5. Adjust the cell width so that it is "slightly" narrower that can be accommodated on one text line. 6. On the leftmost (title) column, double-click the row bordor between rows 2 and 3, to automatically adjust the row height. Now, you can see the entire cell. 7. Save this file and open it again. Now, the row is one text line too short. Thanks.
Created attachment 65024 [details] test file
Created attachment 65025 [details] after opening
Created attachment 65026 [details] after correcting, before saving
Thanks for bugreport reproduced in 3.5.5 and 3.6.0rc on Fedora 64 bit using first attachment not reproduced in 3.3.4, so possible regression Steps to reproduce: 0. Open first attachment in Calc Now we (at least I) see small red triangle in cell K2 1. Select row 2, right mouse click on it's head on left side of screen, select "Optimal row height" from context menu. Now row hight becomes bigger and red triangle disappears. 2. save 3. File->Reload Expected: as before saving Actually: row 2 becomes smaller, not enough room to hold content of cell
I'll take this
(In reply to comment #12) > I'll take this hmm by simple observation ( haven't dug into the code yet ) it does look like the optimal height is run ( at least in 3.6 ) but it seems to ignore the fact the text is broken over 2 lines. On 3.7 opening the file and the height seems good, however things are actually worse, in this case the optimal row height is being ignored ( the actual row height in the xml is used ). you can see this clearly by the fact that reducing the row height and re-running the optimal height ( from the context menu or the double clicking trick ) has no effect whatsoever :-( Seems like 2 separate ( but undoubtedly related problems here )
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=629cd5e1fcdf780cedf7fd88ed7d02492be31411 fix for fdo#49255
Noel Power committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9efd8deb867c89baf0f5df410b87e8310fff524b&g=libreoffice-3-6 fix for fdo#49255 It will be available in LibreOffice 3.6.2.
Noel Power committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e093e553185ed8beff83ef784f0ed5de95c2bc8f&g=libreoffice-3-6 Revert "fix for fdo#49255" It will be available in LibreOffice 3.6.2.
(In reply to comment #16) > Noel Power committed a patch related to this issue. > It has been pushed to "libreoffice-3-6": > > http://cgit.freedesktop.org/libreoffice/core/commit/?id=e093e553185ed8beff83ef784f0ed5de95c2bc8f&g=libreoffice-3-6 > > Revert "fix for fdo#49255" > > > It will be available in LibreOffice 3.6.2. Using Version 3.6.2 Ubuntu 12.04.1 LTS, Arial font. No fix apparent in this version as detailed above.
I see that fixed with parallel installation of Master "LOdev 3.7.0.0.alpha0+ - ENGLISH UI [Build ID: 6900781]" {tinderbox: 2008R2@20, pull time 2012-08-25 21:36:16} on WIN7 Home Premium (64bit) @Tioz With what time machine did you get 3.6.2?
(In reply to comment #17) > (In reply to comment #16) > > Noel Power committed a patch related to this issue. > > http://cgit.freedesktop.org/libreoffice/core/commit/?id=e093e553185ed8beff83ef784f0ed5de95c2bc8f&g=libreoffice-3-6 > > > > Revert "fix for fdo#49255" note: ^^^^ this fix was committed to then reverted from the 3-6 branch, in other words this fix cannot be an any current 3.6 version ( does 3.6.2 even exist yet ? )
fixed on master, marking as fixed
Thanks for fixing this bug
Noel Power committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=390a18bfdccfa9b2334ff0e76800358177f1c661&g=libreoffice-3-6 fix for fdo#49255 It will be available in LibreOffice 3.6.2.
Verified using the nightly build of 2012.08.29, English LibreOffice Calc: http://dev-builds.libreoffice.org/daily/Win-x86_9-Voreppe/libreoffice-3-6/2012-08-29_20.24.59/ Also verified on the master file (on Windows XP) where this test case was extracted. If you have a Calc file created from OpenOffice 3.3, you only have to recalculate optimal row height for all sheets, because in LibreOffice the letters now occupy more width, this causing some of the cells to need one more line in the display. Thanks for solving. I look forward to LibreOffice 3.6.2 on 2012.09.17. Qiyao
(In reply to comment #18) > I see that fixed with parallel installation of Master "LOdev 3.7.0.0.alpha0+ > - ENGLISH UI [Build ID: 6900781]" {tinderbox: 2008R2@20, pull time 2012-08-25 > 21:36:16} on WIN7 Home Premium (64bit) > > @Tioz > With what time machine did you get 3.6.2? (In reply to comment #18) > I see that fixed with parallel installation of Master "LOdev 3.7.0.0.alpha0+ > - ENGLISH UI [Build ID: 6900781]" {tinderbox: 2008R2@20, pull time 2012-08-25 > 21:36:16} on WIN7 Home Premium (64bit) > > @Tioz > With what time machine did you get 3.6.2? Apologies. My current version is 3.6.0.2 A misread when tired. Sorry for any inconvenience. :(
*** Bug 40645 has been marked as a duplicate of this bug. ***
Noel Power committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5f9dae87f7cc6d287892b30cc5b89200f348ea77&g=libreoffice-3-5 fix for fdo#49255 It will be available in LibreOffice 3.5.7. 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.
The original wrong behavior currently exists again in: Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 32; OS: Linux 5.15; UI render: default; VCL: x11 Locale: de-DE (de_DE.UTF-8); UI: de-DE Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.1 Calc: threaded
The issue exists back to version: Version: 7.1.0.0.alpha0+ Build ID: 3870dd43e94c440a5094a57c47d3b7565658d73c CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded I'll test some in the 6.x family next.
What Benjamin and bunkem saw is most likely one of the 6.1.4/6.2.0 regressions in bug 125077, e.g. bug 146668. Subscribe to one of those if you want to follow the issue. Setting this one back to resolved as the fix was verified, and I can see working as expected in 6.0.