Created attachment 153108 [details] Open this file and check the vertical position of the headings Currently the handling of line spacing (before) is inconsistent in the beginning of a page. The line spacing is kept at (1) start of document (2) after a page break But collapsed (3) after a new page caused by a paragraph break IMHO in all the three cases the line spacing should handled the same way, so the headings get vertically aligned regardless you add a page break or not. (BTW, "fixing" this in naive ways breaks existng documents. If you agree that this needs to be fixed, I can help to propose what to do.)
As you said, your story seems to be unique from that by other writers, which I have read. Novel is somehow a fictional story writing in general. But in order to keep the readers thrilled, it should be well written with beauty. Being a journalist, one can get good experience in writing with some flavors. Generally, a journalist needs vast vocabulary and professional usage of the language. https://www.essayjaguar.com/
I confirm that spacing is different in case 3. I also agree, that behaviour should be the same in all three cases. But I would prefer, that case 1 and 2 treat spacing before the same as case 3. Version: 6.4.0.0.alpha0+ (x64) Build ID: 3e64065612acec2eb29aa21e2b515953422256d7 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-08-15_22:57:26 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded and Version: 6.2.5.2 (x64) Build-ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159 CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded
Still present in Version: 7.1.2.1 (x64) / LibreOffice Community Build ID: 094b4116e8de6d2085e9b65d26912d6eac4c74a9 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL But now I'm nin doubt, if that's a bug or the expected result. Behaviour after a paragraph break is correct (no doubt), but perhaps spacing after a page break is also expecte. cc: Design-Team
*** Bug 140877 has been marked as a duplicate of this bug. ***
Created attachment 170998 [details] Screenshot Looks like a bug to me. Use some larger spacing below the paragraph for Text Body- the spacing is cut-off on a new page and the following paragraph put on top without any spacing (neither its own before).
Mike, what do you think?
(In reply to Heiko Tietze from comment #5) > Looks like a bug to me. I totally agree.
Kind of duplicate to bug 50068
(In reply to Dieter from comment #2) > I confirm that spacing is different in case 3. I also agree, that behaviour > should be the same in all three cases. But I would prefer, that case 1 and 2 > treat spacing before the same as case 3. The behavior for spacing after a page break is determined by the compatibility setting "Add paragraph and table spacing at tops of pages". To get the same behavior as case 3 you have to uncheck it.
(In reply to Regina Henschel from comment #9) The compatibility setting that was introduced for compatibility with Word (see #i11859) seems to be never set automatically now (at least it is always checked for new ODF, as well as for RTF, DOC and DOCX as far as I can tell). But its checked state is inconsistent, so I suppose there's still a bug here.
In regards to tools -> options -> Writer -> compatibility "add paragraph and table spacing at tops of pages": This is DocumentSettingId::PARA_SPACE_MAX_AT_PAGES/ParaSpaceMaxAtPages also known as AddSpacingAtPages also known as ADD_PARA_TABLE_SPACING_AT_START/AddParaTableSpacingAtStart [yikes] (In reply to Mike Kaganski from comment #10) > The compatibility setting that was introduced for compatibility with Word > seems to be never set automatically now (at least it is always > checked for new ODF confirmed that compatibility with Word is enabled in almost every case. Seems to be coming from this setting having a value of "true" officecfg/registry/schema/org/openoffice/Office/Compatibility.xcs: <prop oor:name="AddSpacingAtPages" oor:type="xs:boolean" oor:nillable="false"> > as well as for RTF, DOC and DOCX). true for DOC, but not absolutely guaranteed for DOCX/RTF. m_rDoc.getIDocumentSettingAccess().set(DocumentSettingId::PARA_SPACE_MAX_AT_PAGES, true ); //ww8par.cxx > But its checked state is inconsistent, so I suppose there's still a bug here. It defaults to unotools/source/config/compatibility.cxx: setValue<bool>( Index::AddSpacingAtPages, false ); but that seems is irrelevant. I'm not sure what Mike means by being inconsistent. Perhaps because all of these extras/source/autotext/lang/bg/standard/***/settings.xml are set to false? Although it LOOKS like you can save the "off" state as a user default in the UI, it doesn't actually save there. So it appears to me that in NO CASE is it ever off UNLESS THE DOCUMENT SETTINGS turn it off. And THAT could only happen if a user flips that switch. I don't think it is off even for very old documents that pre-date this setting. Advanced settings are needed to change this at the _Default level. At this point I didn't expect to be able to find documents with this value, and yet it seems we have Businesscard-with-logo template and a few other things with this as false. The only actionable conclusion I can come to is ensure that DOCX/RTF have this value set to true.
(In reply to Justin L from comment #11) > I'm not sure what Mike means by being inconsistent. Perhaps because all of > these extras/source/autotext/lang/bg/standard/***/settings.xml are set to > false? I'm sorry for being unclear. I meant that in its checked state, the behavior of the feature is inconsistent (meaning, one can't say that it does what it needs to do to be compatible). Hence I confirmed that this is a bug. Maybe just stating the obvious, sorry :)
I missed the relevance/meaning of this useful bit of info: // mbParaSpaceMaxAtPages def = false, true since SO8 So it sounds like at the introduction of the variable, it was set to false, but it has been true since StarOffice 8 (or something like that). likely from commit 45de8eb0c980f308b668aba9bcdb8f839eaafc38 Author: Kurt Zenker on Mon Aug 2 13:33:08 2004 +0000 A visual inspection suggests that Businesscard-with-logo doesn't need this obsolete setting. So I suggest git grep -l AddParaTableSpacingAtStart *{.fodt,.xml} | xargs sed -i /AddParaTableSpacingAtStart/d
Created attachment 174774 [details] 126677_paraSpacing.docx: last modified by MS Word 2016 - showing 4 instances (In reply to Mike Kaganski from comment #12) > I meant that in its checked state, the behaviour > of the feature is inconsistent (meaning, one can't say that it does what it > needs to do to be compatible). In my observations of how MS Word 2016 acted, I see: 1.) Document start - show the spacing above 2.) Paragraph naturally breaks across a page - don't show spacing above. 3.) Paragraph naturally starts on a new page - don't show spacing above. *4*) Paragraph starts on a new page after a normal page break - don't show spacing above (but LO does...) 5.) Paragraph starts on a new page after a section page break - show the spacing above.
Created attachment 174775 [details] 126677_paraSpacing_Word2016.pdf
Bug 153964 documents the logic of what is happening here, at least for non-section page and column breaks for DOCX. In MS formats, we have a paragraph with a break in it somewhere <w:p> ... some possible runs of text (or shape anchors etc.) w:br type="page" or "column" ... some more possible runs of text </w:p> In LO we have the break as a paragraph property, but in Word it is more of a character property. In LO we have two paragraphs, but in Word it is only one paragraph. And that explains why paragraph top margin, top border, first line indent etc don't apply on the "new page" - because they were already applied to the start of the paragraph on the previous page or column before the break. In older versions of MS Word, that logic wasn't always consistently applied - especially if w:br was the first "run" in the paragraph. Personally, I think it makes sense for a normal paragraph to not have any spacing above when it naturally starts on a new page. The whole point of having spacing is to separate it from other content, and at the top of a page or column it certainly is separated from the previous content. Otherwise it is a waste of space. To make it more export compatible with MS Word, we would need to specify that "top margin" would need to be ignored for normal breaks, and only applied for "with page style" breaks(aka section break). However, I personally like the current consistent ODT logic that any "forced page start" must not ignore top margin for the first paragraph. I would not advise a change for that (unless it is added to a make-LO-work-like-mso compatibility flag).