Bug 48272 - FILEOPEN documents created with OOo: VIEWING pictures and objects with wrong hight and at wrong vertical position.
Summary: FILEOPEN documents created with OOo: VIEWING pictures and objects with wrong ...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
3.3.4 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
Keywords: regression
Depends on:
Blocks: 53228
  Show dependency treegraph
Reported: 2012-04-03 20:17 UTC by Ryszard
Modified: 2012-08-16 10:32 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:

spreadsheet with form and drawing elements (54.98 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-04-03 20:17 UTC, Ryszard
Screenshot comparison (636.67 KB, application/pdf)
2012-06-03 22:26 UTC, Rainer Bielefeld Retired
Even Worse with 3.7.0 (107.46 KB, application/x-download)
2012-08-08 05:55 UTC, Rainer Bielefeld Retired
simplified test case (17.15 KB, application/vnd.oasis.opendocument.spreadsheet-flat-xml)
2012-08-08 07:27 UTC, sasha.libreoffice

Note You need to log in before you can comment on or make changes to this bug.
Description Ryszard 2012-04-03 20:17:59 UTC
Created attachment 59459 [details]
spreadsheet with form and drawing elements

Attached file was created in OpenOffice 2.0, Openoffice 3.3 still opens this file same way as previous version.
In LibreOffice 3.4 and 3.5 placement and sizes of form and drawing elements are different making this document unusable.
Comment 1 Rainer Bielefeld Retired 2012-04-03 23:27:19 UTC
[Reproducible] with "LibreOffice German UI/Locale [Build-ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45f] on German WIN7 Home Premium (64bit) 
[Reproducible] with "LibreOffice 3.4.1RC1  - WIN7  Home Premium (64bit) German UI [OOO340m1 (Build:101)]" 

Looks ok with  "LibreOffice Portable 3.3.0  - WIN7  Home Premium (64bit) German UI [OOO330m19 (Build:6) tag libreoffice-]" (no obvious differences to view in Oo 3.3)

Might be related to a row hight calculation problem or similar. Picture in E16 has hight 5,9mm in 3.5.2 and is located as x/y 43,25mm/78,28mm
With Portable 3.3.0
hight 5.39mmmm and is located as x/y 43.43mm/78.46mm

Some further research will be required
Comment 2 Rainer Bielefeld Retired 2012-06-03 22:24:28 UTC
[Reproducible] with "LibreOffice  German UI/Locale [Build-ID: 165a79a-7059095-e13bb37-fef39a4-9503d18] on German WIN7 Home Premium (64bit) 

[Reproducible] with server-installation of Master "LOdev 3.6.0alpha1+  – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: bfa9061]" (tinderbox: Win-x86@6-fast, pull time 2012-06-02 23:56:11)

It's not only "wrong height".

And I can't tell wether the problem is caused by a bug in OOo + old LibO.

See attached secreenshot comparison for details.

Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
Comment 3 Rainer Bielefeld Retired 2012-06-03 22:26:04 UTC
Created attachment 62485 [details]
Screenshot comparison
Comment 4 sasha.libreoffice 2012-08-07 09:33:46 UTC
reproduced also in 3.3.4 on Fedora 64 bit
Changing version to 3.3.4 as most early reproduced
Comment 5 Ryszard 2012-08-07 23:13:50 UTC
I have installed version, still same problem.
It looks like for all drawings and form( I have only one grouped form object in sample file) object that are anchored to cell program is correctly reading position of lower right corner, but is taking upper left corner of cell as upper left corner of each object anchored to that cell, so is stretching it in different scale depends on original position in cell.
Changing anchor to page will produce correct result, but this is only workaround not solution.
Comment 6 Rainer Bielefeld Retired 2012-08-08 05:55:59 UTC
Created attachment 65263 [details]
Even Worse with 3.7.0

Things become worse in Master, see attached pdf

I created a more simple sample with LibO 3.3.0 and some PDF exports to show different view in various versions. Due to results I created 2 new Bug reports
"Bug 53230 - FILEOPEN particular .ods from LibO 3.0.0 shows all form fields at wrong horizontal position"
"Bug 53229 - FILEOPEN particular .ods from LibO 3.0.0 shows grouped form fields at wrong horizontal position"

Can you please try to extract problems from your sample, to create separate bugs and to add these Bugs to the meta Bug? That might speed up fixing process.
Comment 7 sasha.libreoffice 2012-08-08 05:58:30 UTC
In reply to comment 5: may be Bug 46868 has useful information
Comment 8 sasha.libreoffice 2012-08-08 07:27:34 UTC
Created attachment 65264 [details]
simplified test case
Comment 9 sasha.libreoffice 2012-08-08 07:35:01 UTC
I have copy-pasted part of content.xml of first attachment to fods file. It attached. First cell contains two lines. It is green lines of cell V11 of first attachment.
Here we see that these lines take all cell instead of small part of cell. fodt file contains this line: 
<draw:g table:end-cell-address="Sheet1.A1" table:end-x="0.8606in" table:end-y="0.5878in" draw:z-index="39">

Here we see X and Y dimensions. IMHO it is dimensions of correct green figure (see second attachment). But Calc ignores these dimensions. When I change values in this line in FODS file and reload, nothing changes.
Comment 10 Noel Power 2012-08-16 10:32:56 UTC
I believe the fix for bug 53229 solves this ( at least to my eye the document looks the same when compared with AOo3.4