Created attachment 158926 [details] test odt file The attached test odt file contains page headers. I have unchecked the "Same content first page" in tab "Header" on "Page Style" dialog. The header height for both the first and other pages are set "automatic". It is correctly one paragraph height for header of the first page, and 5 paragraphs height for the second page header. Hoever, when resave as docx, the height of first page header changes to the same as the second page. Steps to Reproduce: 1. Open the attached odt file. --> Observe that the height of first page header is 1-paragraph, and the height of the second page is 5-paragraph height (i.e., the first page header is lower than the 2nd page) 2. Save as docx, close and reopen the docx file. --> The height of first page header changes to the same height as the second page. Current Behaviour: The height of first page header changes to the same height as the second page in the docx file. Expected Result: The height of first page header should remain the same as it was in the odt file.
Created attachment 158927 [details] resaved docx file
Created attachment 158928 [details] pdf of the odt file
Created attachment 158929 [details] pdf of the resaved docx file You may also observe that the bottom border for header is also lost, which may be another issue.
It is confirmed that this is not a FILEOPEN issue as MSO also shows the same result when open the resaved DOCX file.
Thank you for reporting the bug. I can confirm the bug present in Version: 6.4.0.0.alpha1+ (x86) Build ID: ec7374ff84c71edfbb30d6e4dc5b486b6df7107f CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-11-10_21:37:30 Locale: en-US (en_US); UI-Language: en-US Calc: threaded and in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Repro 7.2+. This was improved with LO 5.4 when 1st page header remained, previously with LO 5.3 2nd page header was also there. That's source c027764f94a1fc0a367e03b412d3c11d6c10769c in Bug 109080.
Luke would you please take a look as you have worked on bug 19080?
Hi Kevin. This document has the following header settings: - "Height" set to 0.1cm (silly small) - "AutoFit height" option enabled (so the actual header height will grow to fit its content, pushing down the document text) - "Spacing" set to 0.5cm (so there will be a gap of 0.5cm between the header and the document text) - "Use dynamic spacing" option disabled (so the spacing is maintained even when the header height grows due to the "AutoFit height" option) Unfortunately the docx format does not support this idea of fixed spacing after a non-fixed header height. Word does support a header that can grow down to fit its content, pushing the main document down, but no fixed spacing is supported there. I wonder if you have an opinion about the best compromise we can make here, or anyone else reading this? (1) The current behaviour of LibreOffice is to convert the header to a fixed height, but setting the new height to be the actual header content height plus the spacing. As reported in this bug, this logic fails when the first page header has a shorter content height than the subsequent page headers. (2) Another approach could be to leave the header as non-fixed height, allowing it to grow down according to the height of its content. This will fail to maintain the 0.5cm spacing if the header height grows. (3) Same as (2) plus we could try to add spacing within the header content itself, eg by modifying the style on the final paragraph to add spacing after it. This might actually make the docx look closest to the original odt, but I worry that modifying the header content will be fragile. What do you think?
My opinion (without looking into the specific issue) is that when emulation needs to happen and there is not a clear "right" approach, then just leave things as they other. Otherwise you will likely cause a regression for someone else.
Dear Kevin Suo, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This bug is still present in Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded The bug is also still present in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6a064b1967e06e40be40817deff99d00c1a8554f CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded