Created attachment 131931 [details]
The problematic document with header position set
Attached document has a header position set as 3 cm from top, but in LO 5.3 this setting becomes the page margin from top, creating a lot larger empty space than in Word 2013.
Created attachment 131932 [details]
The document in LO 5.3 and Word 2010 side by side
Reproduced with 184.108.40.206 / Windows 7, but only with default rendering, and not on Ubuntu 16.04, either.
Can not reproduce.
On Windows 10 Pro 64-bit en-US with
Version: 220.127.116.11 (x64)
Build ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new;
Locale: en-US (en_US); Calc: group
The Header layout/spacing is the same LO 5.3.1 and MS Word 2007
I can see that there's a much larger gap above the header (also below the header) in LO 18.104.22.168 than in Word 2013, just like in the screenshots.
Note that in Word there are different settings for the first page, the 3 cm / 1.5 cm header/footer seem to be coming directly from there.
*** Bug 106635 has been marked as a duplicate of this bug. ***
Problem still exist on Writer 22.214.171.124 on 64-bit Windows 10 Creators Update.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Created attachment 143144 [details]
Screenshot in current 6.2 master and Word 2010
While the EMF header looks much better, the top/bottom margin values are still overwritten by header/footer sizes.
Created attachment 143148 [details]
Header settings when opened in current master build
What's maybe not obvious from the screenshot: the original document has "First page different" checked and "Even and odd different" not checked.
Opening the file in LO, both "Same content on left and right pages" and "Same content on first page" are checked.
Several problems here. The first problem to deal with is that the first page is not receiving the "First Page" pagestyle. That is related to the super tiny floating table as the first item in the document. Removing that table results in the first page style showing up. see commit 2e8aad6d45c53d554ccaf26de998ede708cfc289 Author: Vinaya Mandke CommitDate: Thu Apr 24 12:57:51 2014 +0200
fdo#39056 fdo#75431 Section Properties if section starts with table
(Emulation is creating first/follow pages styles instead of different firstpage header in the same style. That is normal, and necessary because the way Word and LO handle sections is completely different. So no worries about comment 10.
And that leads to the First/Follow page being totally different. This is something LO simply cannot do, and gets pretty confusing. In Word, what you see on page 1 is the first-page header for section 1. Because of continuous section breaks the follow-page header is never seen, and neither is the first-page header for section 2. Page 2 displays the follow-page header of section 2. (LO has nothing comparable to continuous sections. Since there is no page break, LO has no way of knowing when to switch to the next page style[Converted2].) This is a CANTFIX.
Dynamic height is also at play in the header size, but that seems to be legitimate.
(In reply to Justin L from comment #11)
> The first problem to deal with is that the first page
> is not receiving the "First Page" pagestyle.
proposed fix: https://gerrit.libreoffice.org/59033ñU
Existing ooxmlexport tests that also start with a table (and have the dummy paragraph) sometimes show the same problem, and sometimes don't. The "fix" doesn't break any of them though, so not sure why some worked anyway - my guess is that they didn't have a blank paragraph in the first cell.
Already OK: 1_page.docx, n780853.docx, table-row-data-displayed-twice.docx, test_segfault_while_save.docx
Fixed: n779642.docx, floating-tables-anchor.docx
Justin Luth committed a patch related to this issue.
It has been pushed to "master":
tdf#106572 writerfilter: don't write to dummy paragraph
It will be available in 6.2.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:
Affected users are encouraged to test the fix and report feedback.
(In reply to Justin L from comment #11)
> Several problems here.
Is it OK to close this bug report? I would rate the header problem as unfixable (unless someone wants to hire a senior programmer for a year to re-write writer internals with a continuous section enhancement) and there are many bug reports already with this as the root cause. The dynamic spacing issue could be somewhat unique, but it probably related to anchor issues which again exists in countless bug reports.
Anyway, I've already convinced myself with that paragraph, so I'll mark it as fixed.
(In reply to Justin L from comment #14)
> (In reply to Justin L from comment #11)
> > Several problems here.
> Is it OK to close this bug report? I would rate the header problem as
> unfixable (unless someone wants to hire a senior programmer for a year to
> re-write writer internals with a continuous section enhancement) and there
> are many bug reports already with this as the root cause. The dynamic
> spacing issue could be somewhat unique, but it probably related to anchor
> issues which again exists in countless bug reports.
> Anyway, I've already convinced myself with that paragraph, so I'll mark it
> as fixed.
Thanks for the fix!
Also thanks for estimating the way to properly fix this, I'll show this my bosses :).