Bug 47545 - FILEOPEN: ODT from OO opens with wrong size of frame set as character
Summary: FILEOPEN: ODT from OO opens with wrong size of frame set as character
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, filter:odt, regression
Depends on: 68767
Blocks: Frame-Dialog
  Show dependency treegraph
 
Reported: 2012-03-19 20:52 UTC by Terrence Enger
Modified: 2024-09-20 21:05 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshots (241.50 KB, application/pdf)
2012-03-19 23:53 UTC, Rainer Bielefeld Retired
Details
comparison of screenshots (234.19 KB, image/png)
2013-09-02 21:39 UTC, Terrence Enger
Details
test ODT from OO (61.48 KB, application/3dr)
2018-01-23 18:26 UTC, Timur
Details
ODT compared (530.53 KB, image/png)
2020-09-16 13:46 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Terrence Enger 2012-03-19 20:52:03 UTC
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.
Comment 1 Terrence Enger 2012-03-19 20:57:29 UTC Comment hidden (obsolete)
Comment 2 Rainer Bielefeld Retired 2012-03-19 23:47:15 UTC
[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
Comment 3 Rainer Bielefeld Retired 2012-03-19 23:53:41 UTC Comment hidden (obsolete)
Comment 4 Joop Kiefte 2012-03-20 09:32:54 UTC Comment hidden (obsolete)
Comment 5 Terrence Enger 2013-08-31 14:39:07 UTC
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.
Comment 6 Joop Kiefte 2013-09-02 06:35:53 UTC
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...).
Comment 7 Terrence Enger 2013-09-02 21:39:21 UTC
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.
Comment 8 Cédric Bosdonnat 2014-01-20 08:57:54 UTC Comment hidden (noise)
Comment 9 Joel Madero 2014-11-05 03:53:13 UTC Comment hidden (obsolete)
Comment 10 Matthew Francis 2015-01-26 04:41:29 UTC
3.6.5.2 shows the URL frame at the start of the document correctly, but 4.0.0.3 places it incorrectly. This is therefore within the range that can be bibisected

Adding Whiteboard:bibisectRequest
Comment 11 Matthew Francis 2015-01-26 09:28:42 UTC
Bibisect results from 43all:
 56de98328b5e6e28aae1f5a8574c4d6500abdf82 is the first bad commit
commit 56de98328b5e6e28aae1f5a8574c4d6500abdf82
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Mon Dec 10 14:11:19 2012 +0000

    source-hash-5f91f8a368343d8921a01edb7359cd300892f09d
    
    commit 5f91f8a368343d8921a01edb7359cd300892f09d

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574
# good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15
git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327
# bad: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e
git bisect bad 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02
# bad: [51b63dca7427db64929ae1885d7cf1cc7eb0ba28] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10
git bisect bad 51b63dca7427db64929ae1885d7cf1cc7eb0ba28
# bad: [446a69834acf747d9d18841ec583512ae8fa42e7] source-hash-06a8ca9339f02fccf6961c0de77c49673823b35f
git bisect bad 446a69834acf747d9d18841ec583512ae8fa42e7
# good: [d2720e99b9e6cb7b099256cc7a6d2b3f907b8d7c] source-hash-7dd6c0a8372810f48e6bee35a11ac4ad0432640b
git bisect good d2720e99b9e6cb7b099256cc7a6d2b3f907b8d7c
# good: [3c228d4685e2981ece0e69cb774dabbef443f77c] source-hash-e63bba0013e5ce34cd04559632206bb7c891eebe
git bisect good 3c228d4685e2981ece0e69cb774dabbef443f77c
# good: [cd18cb7f47f7e956c6d19bd0f31a6e30d1173b29] source-hash-558476135865d9ae7b8801a82c177fd1098386ff
git bisect good cd18cb7f47f7e956c6d19bd0f31a6e30d1173b29
# bad: [56de98328b5e6e28aae1f5a8574c4d6500abdf82] source-hash-5f91f8a368343d8921a01edb7359cd300892f09d
git bisect bad 56de98328b5e6e28aae1f5a8574c4d6500abdf82
# good: [cca0c04dccc1fb2827c929ff2ced5bdb80f915bc] source-hash-179a6db61ee30cf776747802f06edeef45fec461
git bisect good cca0c04dccc1fb2827c929ff2ced5bdb80f915bc
# first bad commit: [56de98328b5e6e28aae1f5a8574c4d6500abdf82] source-hash-5f91f8a368343d8921a01edb7359cd300892f09d
Comment 12 Joop Kiefte 2015-02-22 23:02:49 UTC
Just to check back on this bug I downloaded the source document again and opened it in LibreOffice 4.4. Some parts of the problem are still there as mentioned earlier, so I focused on trying if this is something you could manually fix (which seems to me more pragmatical and actually more serious if that's impossible).

- Trying to resize the text frame right up is impossible.
- Changing the anchoring of the text frame to page makes it jump to the middle of the page and then trying to put it back on location makes LibreOffice 4.4 freeze.

I think this inability to patch up the problem is actually the worst part of this bug, and I sincerely hope this doesn't affect too many people... Any thoughts on those findings of mine?
Comment 13 Robinson Tryon (qubit) 2015-12-13 11:09:40 UTC Comment hidden (obsolete)
Comment 14 QA Administrators 2017-10-23 14:01:22 UTC Comment hidden (obsolete)
Comment 15 Timur 2018-01-23 18:26:23 UTC
Created attachment 139299 [details]
test ODT from OO

ODT from OO opens in newer LO with wrong size of frame set as character.
This was marked as 3.6 but from what I see with a simplified attachment, it started from 4.0.
Comment 16 QA Administrators 2019-08-19 06:54:32 UTC Comment hidden (obsolete)
Comment 17 Timur 2020-09-16 13:46:12 UTC
Created attachment 165572 [details]
ODT compared

Repro 7.1+ as in LO 4.4.
Comment 18 Timur 2020-09-16 13:57:54 UTC
One more bibisect for frame size change:

commit 56de98328b5e6e28aae1f5a8574c4d6500abdf82
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Mon Dec 10 14:11:19 2012 +0000

    source-hash-5f91f8a368343d8921a01edb7359cd300892f09d
    previous source-hash-179a6db61ee30cf776747802f06edeef45fec461
	
    commit 5f91f8a368343d8921a01edb7359cd300892f09d
    Author:     Michael Stahl <mstahl@redhat.com>
    AuthorDate: Thu Sep 20 23:59:14 2012 +0200
    Commit:     Michael Stahl <mstahl@redhat.com>
    CommitDate: Fri Sep 21 18:05:02 2012 +0200
    
        fdo#48692: fix problems with large number of table cells:

https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=179a6db61ee30cf776747802f06edeef45fec461..5f91f8a368343d8921a01edb7359cd300892f09d

Rather large range.
Comment 19 QA Administrators 2022-09-18 04:09:17 UTC Comment hidden (obsolete)
Comment 20 QA Administrators 2024-09-18 03:17:20 UTC Comment hidden (obsolete)
Comment 21 Joop Kiefte 2024-09-20 21:05:16 UTC
Issue still present, version I tested with:

Version: 24.8.1.2 (X86_64) / LibreOffice Community
Build ID: 480(Build:2)
CPU threads: 4; OS: Linux 6.10; UI render: default; VCL: gtk3
Locale: en-US (C.UTF-8); UI: en-US
24.8.1-2
Calc: threaded

I don't think it's incredibly relevant after so many years, but it's probably a nice thing for proper compatibility with old files. I suspect that specific OOo version itself might have had a bug that caused a kinda faulty ODT file as a result at the time... still it would be nice if we can fix that when opening the file...