Bug 80926 - Moving paragraph-bound anchor on ODT file load.
Summary: Moving paragraph-bound anchor on ODT file load.
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All Linux (All)
: low minor
Assignee: Not Assigned
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks: Anchor-and-Text-Wrap
  Show dependency treegraph
Reported: 2014-07-04 19:19 UTC by Jan-Marek Glogowski
Modified: 2017-09-19 12:00 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Test document with broken anchor loading. (8.24 KB, application/vnd.oasis.opendocument.text)
2014-07-04 19:19 UTC, Jan-Marek Glogowski
Document with the same line on 1st, 2nd and 3rd page for debugging. (8.59 KB, application/vnd.oasis.opendocument.text)
2014-07-09 08:56 UTC, Jan-Marek Glogowski
Instrumented LO dbgutil run - gdb output. (26.06 KB, text/plain)
2014-07-14 11:16 UTC, Jan-Marek Glogowski

Note You need to log in before you can comment on or make changes to this bug.
Description Jan-Marek Glogowski 2014-07-04 19:19:55 UTC
Created attachment 102284 [details]
Test document with broken anchor loading.

The attached file just contains a single, paragraph-anchored draw object (a line) on the second page, which has a negative y-Offset.

This is the definition of the line in the ODT:

<draw:line text:anchor-type="paragraph" draw:z-index="0" draw:style-name="gr1" draw:text-style-name="P2" svg:x1="0cm" svg:y1="-1cm" svg:x2="2.88cm" svg:y2="-1cm"><text:p/></draw:line>

So the line should start right above the anchor, but it doesn't, if the zoom factor is larger then 91 on load - at least for me the tipping point is 91, but that may be resolution dependant.

If the zoom factor is higher the 91, the X-offset is moved to the left on load. And it's not a visual glitch, as the "Position and Size" dialog shows the wrong offset. If you save or print the document, it's broken. If the document is saved and loaded, the anchor is aved wrong and it moves again on load depending on the zoom value.

I actually did a *bi*bisect without knowing about the "Zoom" factor, and the bug showed up first at a7e54955e9f49e8b59dfd8c4533785a680b1796c, but this might be bogous, as I didn't knew anything about Zoom at this time.
Comment 1 Jan-Marek Glogowski 2014-07-04 19:48:15 UTC
Ok - I just did another bibisect and I realized the same effect always happens, if your screen is wide enought to show two pages side by side.

And this happens to me in all versions. Steps to reproduce:

1. Open the LO with the attached file.
2. Change the size of the window, so the two pages are shown side by side.

The anchor is still correct, so is the displayed line!

3. Close LO.
4. Start LO with the file.

LO shows both pages and the line has moved to the left. This even happens independend from the Zoom factor!
Comment 2 Jan-Marek Glogowski 2014-07-04 19:55:45 UTC
Just tested our good, old OOo 3.2.1, which works correct.
Comment 3 Yousuf Philips (jay) (retired) 2014-07-06 01:11:12 UTC
Confirmed in Linux Mint in 3.6.7, 4.2.5 and master. It didnt happen in 3.3.0 as when i reopened the file, it didnt show the two pages side by side.
Comment 4 Jan-Marek Glogowski 2014-07-09 08:56:53 UTC
Created attachment 102471 [details]
Document with the same line on 1st, 2nd and 3rd page for debugging.
Comment 5 Jan-Marek Glogowski 2014-07-09 09:07:36 UTC
Just as an information: this is also broken in AOO 4.1.

I've started to debug SwToCntntAnchoredObjectPosition::CalcPosition using the extended test document with three pages. But the the problem seems to be outside of the CalcPosition function, because the arguments to _CalcRelPosX is already broken.

  SwFmtHoriOrient aHori( rFrmFmt.GetHoriOrient() );

creates an already wrong object. The object for page 1 + 3 (and all other pages) is:

$1 = (SwFmtHoriOrient) {
  <SfxPoolItem> = {
    _vptr.SfxPoolItem = 0x640e37e8, 
    m_nRefCount = 0, 
    m_nWhich = 102, 
    m_nKind = 0
  members of SwFmtHoriOrient: 
  nXPos = 0, 
  eOrient = 0, 
  eRelation = 0, 
  bPosToggle = false

while for page 2 it is:

$2 = (SwFmtHoriOrient) {
  <SfxPoolItem> = {
    _vptr.SfxPoolItem = 0x640e37e8, 
    m_nRefCount = 0, 
    m_nWhich = 102, 
    m_nKind = 0
  members of SwFmtHoriOrient: 
  nXPos = -1706, 
  eOrient = 0, 
  eRelation = 0, 
  bPosToggle = false

I also checked the ODTs content.xml. Here is the output for page 2 and 3:

<style:style style:name="P1" style:family="paragraph" style:parent-style-name="Standard">
  <style:paragraph-properties fo:break-before="page"/>

<text:p text:style-name="P1">
  <draw:line text:anchor-type="paragraph" draw:z-index="1" draw:style-name="gr1" draw:text-style-name="P2" svg:x1="0in" svg:y1="-0.3799in" svg:x2="1in" svg:y2="-0.3799in">
<text:p text:style-name="P1">
  <draw:line text:anchor-type="paragraph" draw:z-index="2" draw:style-name="gr1" draw:text-style-name="P2" svg:x1="0in" svg:y1="-0.3799in" svg:x2="1in" svg:y2="-0.3799in">

If you manually correct the X value of the 2nd line after loading using the GUI (to 0in) and save the document, you don't get svg:x1="0in" and svg:x2="1in" but a fraction smaller values.

I'm still trying to understand the styles.xml; even for this simple document it's kind of "huge". Probably someone else can spot a problem, but for me it looks correct.

Currently I'm looking for the code, where the SwFmtHoriOrient of the SwFrmFmt is actually initialized (or changed).
Comment 6 Christoph Lutz 2014-07-11 16:03:59 UTC
I opened your document test-line3.odt with LO on Windows and noticed
that on the second page the line ist moved little bit in direction "top left" and on the third page it is moved another little bit in this direction (so here it is really close to the left top of the page corner).

I then manually edited the content.xml to add some more of these paragraphs (with that line) and from the 4th page on, it looks like on page one.
Comment 7 Jan-Marek Glogowski 2014-07-14 11:16:01 UTC
Created attachment 102765 [details]
Instrumented LO dbgutil run - gdb output.

The attached text shows the origin problem. Actually it also happens in all OOo versions I tested. The layouting code is already broken.

    commit 09f50c017fe106b7bf94f60933667b55130ea1b5  
    commit 120922361a5928ea4437ffe253ce209abd7060b0
really broke it.

For the trace I was using a document with two pages and two "lines".

All ratios are approximations. The actualy sizews are much larger, more like "10000 x 25000" for the two page view. All the layouting in LO is absolute. 

So LO is doing the initial full layouting (incl. anchored frames) just for the visible pages, partial layouting for the for the next page / rest. At this point the view is still "initial", and just has space for a single page. All the layouting of the "hidden" pages is going to be done later. So the 2nd page is invisible.

The document with two pages has the size "100 x 400". The initial view is "120 x 150". Every page has the size "80 x 150". There are spaces between and gray area around the page.

And there comes the "resize view". This changes the visual area to "220 x 150", but the layouting is still based on the single page layout (100 x 400).

So the actually IsShortCut checks the new view against the old layout, which basically says, that the 2nd page is still outside of the view, so the additional layouting can be skipped:

sw/source/core/layout/layact.cxx:1146    bRet = true;

An initial "fix" is included in private/jmux/layout-fixes, which prevents moving anchors of invalid pages on view resize. Actually this code should never happen.

I'm still looking for a real fix.
Comment 8 Commit Notification 2014-09-10 19:56:22 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":


fdo#80926 Don't move anchors of invalid pages

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:
Affected users are encouraged to test the fix and report feedback.
Comment 9 Robinson Tryon (qubit) 2015-12-14 00:44:41 UTC Comment hidden (obsolete)
Comment 10 Xisco Faulí 2016-09-23 15:42:33 UTC
Is this bug fixed?
If so, could you please close it as RESOLVED FIXED?
Comment 11 Björn Michaelsen 2017-09-18 23:09:29 UTC
(In reply to Xisco Faulí from comment #10)
> Is this bug fixed?
> If so, could you please close it as RESOLVED FIXED?

Just assuming so now.
Comment 12 Jan-Marek Glogowski 2017-09-19 12:00:43 UTC
So this workaround fixes the bug. I spend some time in analysing the layout code to fix the underlying problem, where some part of layout works with old, other with new values, but eventually gave up.

Guess nothing is more stable then temporary, workaround code ;-)