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.
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!
Just tested our good, old OOo 3.2.1, which works correct.
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.
Created attachment 102471 [details] Document with the same line on 1st, 2nd and 3rd page for debugging.
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. sw/source/core/objectpositioning/tocntntanchoredobjectposition.cxx:982 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"/> </style:style> <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/> </draw:line> </text:p> <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"> <text:p/> </draw:line> </text:p> 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).
I opened your document test-line3.odt with LO 4.2.0.4 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.
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. Actually commit 09f50c017fe106b7bf94f60933667b55130ea1b5 and 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.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=508d2d2b1a6a23043c8c0f0d3fea4ec033ac2684 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Migrating Whiteboard tags to Keywords: (bibisected, filter:docx) [NinjaEdit]
Hello, Is this bug fixed? If so, could you please close it as RESOLVED FIXED?
(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.
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 ;-)