Calc damage .ods files on Charting Opening and immediately saving an .ods file with Charts, some of them are permanently damaged. Some Charts are deformed "doubling" the vertical size and the inside fonts are very narrow and tall. Additional notes: The original .ods file is show correctly in OpenOffice3.3.0 and in LibreOffice3.5.0 Re-saving the file with OpenOffice3.3.0, the chart in the .ods file is still correctly seen with both suites. Re-saving the file with LibreOffice3.5.0, the chart in the .ods file is damaged with both suites. Trying to resize the deformed Charts, never get the original look.
Created attachment 57311 [details] saved with OO3.3.0
Created attachment 57312 [details] saved with LO3.5.0
Created attachment 57313 [details] how I see the Charts and row height
This generate an incompatibility to existent .ods electronic sheet.
I found a workaround: Setting the row height where the Chars is, restore the original charts aspect ratio. This is not manual/practical if the row are all different in height. Worse the height in damaged files are wrong down to the last line in sheet ...
[Reproducible] with "LibreOffice 3.4.5 German UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit). Steps to reproduce: 1. open sample document 2. Save under new name without edits 3. close 4. reopen Starting with row 54 row height recalculation causes a much bigger row height what stretches the charts Also with LibO 3.5.0 Works fine with 3.3.0, so REGRESSION Sample document saved with LibO 3.3.0 also suffers from the problem. Not reproducible with simple own sample documents created with OOo 3.1.1 @Valerio Messin What's your OS?
[Reproducible] with "LibreOffice 3.4.1RC1 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:101)]"
My OS is WinXP sp3 it UI (I think this is not related) Happen on LO with UI set to "English (USA)" and "Italian" too
Currently only WIN confirmed (I also expect that it's for all OS) @Valerio Messina <http://wiki.documentfoundation.org/BugReport_Details#Version> @Kohei: Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
About Version, my web client reset the field to 3.5, and I have not noticed, sorry Set again to 3.4.1 RC1
happened again for platform. Probably is a refresh conflict
Confirmed on coLinux: vmessina@speedLinux:~$ uname -a Linux speedLinux 2.6.33.7-co-0.7.9-r1581 #1 PREEMPT Sat Apr 9 21:08:08 UTC 2011 i686 i686 i386 GNU/Linux vmessina@speedLinux:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu precise (development branch) Release: 12.04 Codename: precise Libreoffice .deb package 1:3.5.0~beta2-2ubuntu4
confirmed on Ubuntu: efa@02cor2133:~$ uname -a Linux 02cor2133 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:50:54 UTC 2012 i686 i686 i386 GNU/Linux efa@02cor2133:~$ lsb_release -a LSB Version: core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:core-4.0-ia32:core-4.0-noarch Distributor ID: Ubuntu Description: Ubuntu 11.10 Release: 11.10 Codename: oneiric Libreoffice .deb package 1:3.4.4-0ubuntu1
OS due to comment 13
When a chart is cell-anchored it's supposed to change its size when the row height changes. It's by design. If you don't want this, anchor charts to page, not to cell.
not a regression.
the bug is about opening and resaving a .ods file, many rows changes height
the refreshing browser problem caused the unvolontary change in many properties. I back Status to the last one
I do not know how to restore "Ever confirmed" to 1
Ah ok. So this is an import problem. Re-opening. Still not a regression since the drawing object handling has been massively re-worked. But just a regular bug for the new feature.
which new feature?
@Kohei: If th remaining Subject is "FILESAVE: unexpected row height recalculation" we should delete the rest to avoid confusion.
(In reply to comment #21) > which new feature? drawing object re-work.
Changing the subject.
> drawing object re-work. isn't a feature at all
(In reply to comment #25) > > drawing object re-work. > > isn't a feature at all Only to a mere user. That's all I gotta say.
about Summary: as explained in first post, the error is not on import. It is the file on save phase that become damaged, as once saved by LO, the row height is wrong also opening in OO3.3
(In reply to comment #27) > about Summary: as explained in first post, the error is not on import. > It is the file on save phase that become damaged, as once saved by LO, the row > height is wrong also opening in OO3.3 Noted.
Talked to Kohei on IRC. Will look into the issue.
I have a fix for it and maybe for some more problems related to this one. The problem has been that after the sc drawing layer rework the drawing layer objects are no longer counted as part of the used area. After that the styles of the now unused area have not been exported to the file. Just need to check whether we shouldn't export all styles instead of only the styles from the used area.
Fixed it now by exporting all row styles to the target document.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=766931e1de1adee987108d59d96431dc41cd2d96&g=libreoffice-3-5 export all row styles, fdo#46336 It will be available in LibreOffice 3.5.2.