summary ------- FILEOPEN,VIEWING: different position of some items description ----------- This bug originates from Joop Kiefte's message to the dev list "Worked in OOo, doesn't load well in LibO" <http://lists.freedesktop.org/archives/libreoffice/2012-March/028529.html>, in which he asks "Can anyone identify what's the problem in this document or in LibreOffice?". The document in question is <http://lists.freedesktop.org/archives/libreoffice/attachments/20120319/3b20cf3a/attachment-0001.odt>. My observations ... (1) The document is rendered differently on both screen and in print by LibreOffice 3.3.4, as distributed with ubuntu-natty and by local build from master commit id cc32ce4 (pulled 2012-03-09), configured with --disable-mozilla --enable-symbols --enable-dbgutil --enable-crashdump --disable-build-mozilla --without-system-postgresql --enable-python=internal I shall attach pdf's from each of my available versions of LO. I think the first one looks better, but @Joop: can you please confirm this opinion? (2) The validator at <http://odf-validator.rhcloud.com/> reports 2 errors and 11 warnings. The message FN2011-08_copy.odt/styles.xml[2,35942]: Error: unexpected attribute "fo:min-width" in particular catches my attention. (3) My local build displays this message four times while opening the document ... warn:legacy.osl:7195:1:/home/terry/lo_hacking/git/libo/sw/source/core/layout/flylay.cxx:1023: ::CalcClipRect(..) - frame, vertical position is oriented at, is missing . Bug search finds the following near misses: (*) 37532 "FILEOPEN particular .docx shows wrong position for pictures in heading" Some of the repositioned items are pictures, but the document is .odt, not .docx. (*) 40344 "[regression] graphics / objects in older documents positioned wrong" Could be the same, but that bug was fixed in 350rc1 (2012-01-24) and I still see questionable results.
Cannot attach the pdf's I promised: too big.
[Reproducible] with "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit). When I delete text frame with "FractieNieuws" and picture "CristenUnie" arrangement of remaining items looks better. I' can't find out what exactly might cause the problem Looks fine with "LibreOffice 3.4.5 German UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit), so REGRESSION Problem appeared somewhere between LibO-dev 3.5.0 Build ID: 3b32204-7f92fce-2ba0a9f 2011-09-03 (broken) and Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID:d337f79-a24c961-2865670-9752b71-7f8fd43 2fdd60d-fd28b6a-fd7bf20-aa369cb-28da3fb 6a9633a-931d089-ecd263f-c9b55e9-b31b807 82ff335-599f7e9-bc6a545-1926fdf)]" from (July 2011) I doubt that mentioned Bugs "Bug 35324 - FILEOPEN: In particular .docx pictures arrangement wrong" "Bug 37523 (!) - FILEOPEN particular .docx shows wrong position for pictures in heading" are related, those bugs where observed in LibO 3.3, where the problem of this report does not appear. @Cédric: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
Created attachment 58725 [details] Screenshots Show how it looks in LibO 3.5.1 and OOo 3.1.1
Just to confirm that the screenshot correctly represents the problem.
The problem seems to be gone with master commit 139a7d5, fetched 2013-08-28. @Joop: Please check with your next version of LibreOffice. If you like the result, set the status of this bug to VERIFIED. Terry.
It looks very close, but for some reason the frame with the internet address is still showing up too low for me (maybe because I don't have the very last build right now, if somebody can verify this is different between the version in Ubuntu 13.04 and the last build, I can try to get one of those and verify...).
Created attachment 85091 [details] comparison of screenshots In particular, the version on the left is a screenshot of F1,pdf that I think shows the desired rendering; the version on the right is from master commit a6a06e0 pulled 2013-09-01 21:05 Z. The attachment is a screenshot of BeyondCompare. @Joop: I should have looked more closely before closing the bug report. Terry.
Restricted my LibreOffice hacking area
Looks confirmed so moving to NEW as REOPENED is incorrect status.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.