Created attachment 166616 [details] Example doc file from Word When opening Word .doc document, where top margin is set to 1.5cm, bottom 0.51cm and both header and footer are set to be 1.25 cm from edge, end result is incorrect paging and layout because Writer includes header and footer under page margins. In this case Writer actually has only top margin correct 1.5cm. Imported doc file shows also 1.5 bottom margin instead of 0.51cm leading to incorrect paging and of course both header and footer are at wrong place.
I'm sorry, what is the problem handled here in this issue? The title says "Need separate page and header/footer margin settings like in Word", making impression that there's something functionally absent in Writer's means of controlling the page dimensions and header/footer. (This might be a misconception; FAQ [1] describes a page model of Writer, which is conceptually different from Word's, but which allows controlling the page dimensions and parts precisely; there are page setups possible in Writer that aren't possible in Word, and vice versa, because of the fundamental difference in the model.) But the description tells about something different: about wrong import of a given document, which is not because of the missing "separate settings", but because of, well, a bug in import code. So what should be the topic here? [1] https://wiki.documentfoundation.org/Faq/Writer/PageElementSizeRelations
This is actually a question to those, who decide best way to fix this import problem. I see several ways to fix this but none of those probably without side effects and might require big(ish) changes. RTF version of the same document imports nicely and PDF version shows expected layout. All 3 formats (DOC, RTF, PDF) available: DOC version: https://www.kissaliitto.fi/wpolku/media/2019/12/astutussopimus_20.doc RTF version: https://www.kissaliitto.fi/wpolku/media/2019/12/astutussopimus_20.rtf PDF version: https://www.kissaliitto.fi/wpolku/media/2019/12/astutussopimus_20.pdf Probably best way would be adding Word type separation also to Writer. It gives flexibility and would make interoperability easier. Without knowing details about Writer implementation however hard to say.
(In reply to Ari Latvala from comment #2) > This is actually a question to those, who decide best way to fix this import > problem. OK, so this is import problem then. Repro with Version: 7.0.2.2 (x64) Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994 CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL
To be more precise. One obvious bug in this document import is wrong bottom margin (DOC has 0.51cm but imported version has 1.5cm. However if bottom margin is changed in Writer to 0.51, that means that footer is then too near the page edge, should be 1,25cm. So one way or another, end result is incorrect layout. Another obvious problem is at the beginning of the second page, where text starts too low even if the bottom margin is set to 0.51cm manually. There seems to be an empty header row above the actual text part causing this. Without manual bottom margin setting change to 0.51cm situation is even worse on the second page because last two line breaks from page one move to the second page. Without having a separate "Distance from page edge" setting for header and footer I find it difficult to fix this kind of import layout problem but again hard to tell without knowing exact details of current implementation.
(In reply to Ari Latvala from comment #4) > Without having a separate "Distance from page edge" setting for header and > footer I find it difficult to fix this kind of import layout problem There's nothing here requiring anything like that. We just need to import it exactly like we do for RTF counterpart: use dedicated page style for the first page, and different style for the rest. This is how it's handled in Writer.
Created attachment 166655 [details] Example doc compared MSO 2016 LO 7.1+ Here is DOC comparison.
Created attachment 166656 [details] Example doc compared MSO 2016 LO 7.1+ Here is DOC comparison with footer, better than attachment 166655 [details]. MSO page with small margin of 0,51 cm overlaps footer of 1,25 cm.
In MSO, there are 2 empty lines at the bottom of page 1. In LO 4.0, there was 1 line at the bottom of page 1. In LO 4.1, there were no lines at the bottom of page 1. (Later, there was regression an it was fixed for the document, but regardless, I'll mark Version from 4.1.0). Bibisect Lin 4.1, single commit: commit f1e99f38d537693ab8d73d721421f43d82b365b2 Date: Fri Sep 18 10:29:41 2015 +0800 source-hash-1e113cb7604e1509e7d598a9be329f1f7b6e9322 previous source-hash-532e25f8b0ef1daeca1f9f84c7084812b72841d5 commit 1e113cb7604e1509e7d598a9be329f1f7b6e9322 Author: Luke Deller <luke@deller.id.au> AuthorDate: Sun Feb 10 02:31:47 2013 +1100 Commit: Tor Lillqvist <tml@iki.fi> CommitDate: Mon Feb 11 10:41:05 2013 +0000 import different first page header/footer from doc I add Luke to CC.
(In reply to Timur from comment #8) > commit 1e113cb7604e1509e7d598a9be329f1f7b6e9322 > Author: Luke Deller <luke@deller.id.au> > AuthorDate: Sun Feb 10 02:31:47 2013 +1100 > Commit: Tor Lillqvist <tml@iki.fi> > CommitDate: Mon Feb 11 10:41:05 2013 +0000 > > import different first page header/footer from doc Oh, that seems it: > When a Word section has a different first page header/footer, > this used to be imported into LO as a chain of two page styles. > Now that LO supports a single page style with different first page > header/footer we can import to that. That was really wrong thing to do. Our "single page style with different first page header/footer" means different contents of the header/footer, but not different presence/absence of the header/footer for first page and the rest. In this case, where first page should have *no* footer, and the second has one, the previous approach should had been used.
This document has two continuous section breaks on the first page. LO has absolutely nothing resembling continuous breaks. That makes this a duplicate of bug 89297. *** This bug has been marked as a duplicate of bug 89297 ***