Bug 126677 - Inconsistent behavior handling paragraph spacing at the beginning of a page
Summary: Inconsistent behavior handling paragraph spacing at the beginning of a page
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 140877 (view as bug list)
Depends on:
Blocks: Paragraph-Spacing
  Show dependency treegraph
 
Reported: 2019-08-02 14:39 UTC by lwchkg
Modified: 2023-03-24 13:38 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Open this file and check the vertical position of the headings (9.33 KB, application/vnd.oasis.opendocument.text)
2019-08-02 14:39 UTC, lwchkg
Details
Screenshot (8.98 KB, image/png)
2021-04-07 10:50 UTC, Heiko Tietze
Details
126677_paraSpacing.docx: last modified by MS Word 2016 - showing 4 instances (12.03 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-09-04 13:27 UTC, Justin L
Details
126677_paraSpacing_Word2016.pdf (94.37 KB, application/pdf)
2021-09-04 13:27 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lwchkg 2019-08-02 14:39:20 UTC
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.)
Comment 1 Kelly Kevin 2019-08-09 04:53:26 UTC Comment hidden (spam)
Comment 2 Dieter 2019-08-26 10:56:21 UTC
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
Comment 3 Dieter 2021-03-23 07:07:52 UTC
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
Comment 4 Dieter 2021-03-23 07:08:57 UTC
*** Bug 140877 has been marked as a duplicate of this bug. ***
Comment 5 Heiko Tietze 2021-04-07 10:50:54 UTC
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).
Comment 6 Heiko Tietze 2021-04-07 10:51:17 UTC Comment hidden (obsolete)
Comment 7 Mike Kaganski 2021-04-07 12:31:31 UTC
(In reply to Heiko Tietze from comment #5)
> Looks like a bug to me.

I totally agree.
Comment 8 Heiko Tietze 2021-04-07 12:42:31 UTC
Kind of duplicate to bug 50068
Comment 9 Regina Henschel 2021-04-07 13:07:33 UTC
(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.
Comment 10 Mike Kaganski 2021-04-07 14:44:12 UTC
(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.
Comment 11 Justin L 2021-08-27 14:25:53 UTC
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.
Comment 12 Mike Kaganski 2021-08-27 14:36:47 UTC
(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 :)
Comment 13 Justin L 2021-08-27 18:19:51 UTC
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
Comment 14 Justin L 2021-09-04 13:27:19 UTC
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.
Comment 15 Justin L 2021-09-04 13:27:46 UTC
Created attachment 174775 [details]
126677_paraSpacing_Word2016.pdf
Comment 16 Justin L 2023-03-24 13:38:27 UTC
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).