Description: For the attached docx document, LO renders the footer twice: once at the correct position, and once a little bit on the side. I'll attach a pdf that shows how my 5.4.1.2 release renders the document, but I see the same behavior with a nightly build from September 16. Actual Results: Expected Results: Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Created attachment 136298 [details] The file that triggers the problem
Created attachment 136299 [details] The file as rendered by LO 5.4.1.2
Giving it a second look, the second footer is not identical to the first one. Rather, it seems to be an old version or a footer template.
Confirmed in Version: 6.0.0.0.alpha0+ Build ID: 83288332f7ced698610739419989c464256f1c4d CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group Version: 5.2.0.0.alpha1+ Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; Locale: ca-ES (ca_ES.UTF-8) Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Created attachment 136582 [details] minimial docx file causing the bug A minimal version of the docx file. In MSO it rendered completely blank. In current master of LO the "false" footer is still there. It is located in the footer3.xml and looks basically like a normal footer...
I can comment on this bug: The document.xml reads [...] <w:headerReference w:type="even" r:id="rId7"/> <w:headerReference w:type="default" r:id="rId8"/> <w:footerReference w:type="even" r:id="rId9"/> <w:footerReference w:type="default" r:id="rId10"/> <w:headerReference w:type="first" r:id="rId11"/> <w:footerReference w:type="first" r:id="rId12"/> [...] <w:titlePg/> [...] "rId9" is the label of "footer1.xml" -> even "rId10" is the label of "footer2.xml" -> default "rId12" is the label of "footer3.xml" -> first The ooxml standard says: if <w:titlePg/> appears in the section (and it does) the "first page footer" has to be used. And this is here the case (footer3.xml)! Following the specification, LO does not do anything wrong here. Question is, why MSO uses the "even page footer" (footer1.xml) on the title page?
> Following the specification, LO does not do anything wrong here. Question > is, why MSO uses the "even page footer" (footer1.xml) on the title page? Maybe Justin Luth can help you here... recently he has been doing some changes in the footer, if I recall well..
hi, me again. I was completely on the wrong way. Both LO and MSO try to render the same footer (footer3.xml). The misplaced textboxes are anchored in the footer, but they have a relative vertical distance of about one entire page. Thus, their absolute position would be far below the page border. LO now cuts the distance in sw/objectpositioning to make the boxes fit on the page (therefore they are located a the very bottom). MSO seems to ignore the boxes and makes them unreachable for the user.
(In reply to Patrick Jaap from comment #8) > The misplaced textboxes are anchored in the footer, > but they have a relative vertical distance of about one entire page. Thus, > their absolute position would be far below the page border. > MSO seems to ignore the boxes and makes them unreachable for the user. LibreOffice shows the footer content from the minimal test in comment 5 as far back as I can go in bibisect43all - 3.5. My personal opinion is that it is good for lost "junk" to become visible so that it can be cleaned up and removed. I'm not interested in this particular bug.
Apologies, but I have to disagree. I know that my test files are full of historical crap, but these are files that people actually use, like it or not. My potential users don't care at all about the intricacies of the docx file format. If LO will not properly display a file that they have been working with without problems using MSOffice, then LO will not be used. To be a bit more constructive, how about the following compromise: When opening a file with off-page content, ask the user about what should be done. Possible choices: "move to visible area" and "remove".
I have a patch on gerrit https://gerrit.libreoffice.org/#/c/43313/ which actually resolves this issue. But I need some feedback since it is just an idea. I want to block off-page content if a file is loaded and only allow adjusting the position of text boxes if I am editing the file.
Patrick Jaap committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8d62b79f168180c6992eb483ec864d473050635f tdf#112443 disable off-page content positioning It will be available in 6.1.0. 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.
I confirm that the issue is fixed. Many thanks to all! Can this be backported to the 6.0 branch?
Patrick Jaap committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=529924a29ce6f688337f91de9dcf1aa9869e91ad&h=libreoffice-6-0 tdf#112443 disable off-page content positioning It will be available in 6.0.0.2. 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.
This is fixed.