Bug 131531 - FILESAVE ODT->DOCX: Header height of first page is not reserved
Summary: FILESAVE ODT->DOCX: Header height of first page is not reserved
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.0.3 release
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:docx
Depends on:
Blocks: DOCX-Header-Footer
  Show dependency treegraph
 
Reported: 2020-03-24 13:03 UTC by Kevin Suo
Modified: 2024-04-19 14:52 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
test odt file (11.64 KB, application/vnd.oasis.opendocument.text)
2020-03-24 13:03 UTC, Kevin Suo
Details
resaved docx file (5.48 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-03-24 13:04 UTC, Kevin Suo
Details
pdf of the odt file (10.19 KB, application/pdf)
2020-03-24 13:07 UTC, Kevin Suo
Details
pdf of the resaved docx file (10.10 KB, application/pdf)
2020-03-24 13:08 UTC, Kevin Suo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Suo 2020-03-24 13:03:18 UTC
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.
Comment 1 Kevin Suo 2020-03-24 13:04:36 UTC
Created attachment 158927 [details]
resaved docx file
Comment 2 Kevin Suo 2020-03-24 13:07:11 UTC
Created attachment 158928 [details]
pdf of the odt file
Comment 3 Kevin Suo 2020-03-24 13:08:52 UTC
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.
Comment 4 Kevin Suo 2020-03-24 13:10:49 UTC
It is confirmed that this is not a FILEOPEN issue as MSO also shows the same result when open the resaved DOCX file.
Comment 5 Durgapriyanka 2020-03-25 20:45:54 UTC
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
Comment 6 Timur 2021-05-28 12:12:08 UTC
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.
Comment 7 Kevin Suo 2021-08-23 01:17:44 UTC
Luke would you please take a look as you have worked on bug 19080?
Comment 8 Luke Deller 2021-08-23 12:59:59 UTC
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?
Comment 9 Justin L 2021-08-27 05:13:49 UTC
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.
Comment 10 QA Administrators 2023-10-02 03:15:36 UTC Comment hidden (obsolete, spam)
Comment 11 wjsim 2024-03-08 19:34:18 UTC
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