Bug 73590 - FORMATTING: ODF imported paragraph style can not override only margin-top or -bottom with zero
Summary: FORMATTING: ODF imported paragraph style can not override only margin-top or ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: ODF-import
  Show dependency tree / graph
 
Reported: 2014-01-14 07:41 UTC by Jim Avera
Modified: 2024-12-03 16:59 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
Demo showing paragraphs which don't respect margin-top in default style (7.57 KB, application/vnd.oasis.opendocument.text)
2014-01-14 07:41 UTC, Jim Avera 		Details
Calligra vs LibO (113.91 KB, image/png)
2014-05-30 07:34 UTC, Yousuf Philips (jay) (retired) 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Avera 2014-01-14 07:41:23 UTC 
Created attachment 92018 [details]
Demo showing paragraphs which don't respect margin-top in default style

This bug reports a problem where LO seems to mis-interpret certain ODF constructs which it itself does not generate; but the result is wrong behavior when importing .odt files created by other apps which use them.

I have only limited understanding of the ODF specification, so please accept my apologies if this is not really a bug...

If the default paragraph style specifies non-zero values for both fo:margin-top or fo:margin-bottom, and a regular style overrides just one of them with zero, then the other property in the default style is ignored or forced to zero.

That is, if a regular style (whether 'common' or 'automatic') specifies *either* fo:margin-top or -bottom with a zero value, but not both, then the other one is forced to zero and all spacing between paragraphs disappears.

(Note: The "reverse" situation works correctly, where the default style specifies zero values and the overriding style overrides only one of them with a non-zero value).

Attached is a demo file.  Inside it is the following

  styles.xml contains

    <style:default-style style:family="paragraph">
      <style:paragraph-properties fo:margin-bottom="1cm" fo:margin-top="1cm"/>
    </style:default-style>

    <style:style style:class="text" style:family="paragraph" style:name="MyStyle">
      <style:paragraph-properties fo:margin-bottom="0cm"/>
    </style:style>

  content.xml contains

  <text:p text:style-name="MyStyle">This is paragraph #1</text:p>
  <text:p text:style-name="MyStyle">This is paragraph #2</text:p>
  <text:p text:style-name="MyStyle">This is paragraph #3</text:p>
  <text:p text:style-name="MyStyle">This is paragraph #4</text:p>
  <text:p text:style-name="MyStyle">This is paragraph #5</text:p>

Actual result:
  All paragraphs displayed with zero space between

Expected result:
  1cm space above each paragraph (from margin-top=1cm in the default style)

Operating System: Ubuntu
Version: 4.2.0.2 rc
Comment 1 Yousuf Philips (jay) (retired) 2014-05-30 06:55:56 UTC 
Confirmed in Linux Mint in the latest releases from 3.6 to 4.2 and 4.3 beta. It is rendered different in Calligra Words 2.8 and Microsoft Word 2010.
Comment 2 Yousuf Philips (jay) (retired) 2014-05-30 07:34:31 UTC 
Created attachment 100146 [details]
Calligra vs LibO
Comment 3 QA Administrators 2015-06-08 14:42:05 UTC Comment hidden (obsolete)
Comment 4 Jim Avera 2015-06-09 00:52:36 UTC 
Problem is still there in 5.0.0.0.beta1+
Comment 5 QA Administrators 2016-09-20 10:01:08 UTC Comment hidden (obsolete)
Comment 6 Regina Henschel 2016-09-20 21:02:34 UTC 
The problem with a single fo:margin-nnn setting is still there.

If LO writes the file itself, it writes always fo:margin-bottom and fo:margin-top together. That hides the parent value.

In contrast to the combining attribute fo:margin, it is allowed, that only one of the four possible settings is used and it does not automatically include other sides.

I have tested Version: 5.3.0.0.alpha0+
Build ID: ba269f7294e2416659011cbb498a2c6b5f9d5199
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-09-12_02:36:16
Locale: de-DE (de_DE); Calc: group
Comment 7 Jim Avera 2016-09-21 21:30:11 UTC 
Bug still there in 5.2.3.0.0+
Comment 8 Xisco Faulí 2017-09-29 08:49:14 UTC Comment hidden (obsolete)
Comment 9 Regina Henschel 2017-09-29 11:27:15 UTC 
The error still exists in Version: 6.0.0.0.alpha0+
Build ID: fc61be93c60967bf1d6bcffcada8189016d4530e
CPU threads: 4; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-09-04_23:40:52
Locale: de-DE (de_DE); Calc: group
Comment 10 QA Administrators 2018-09-30 02:49:32 UTC Comment hidden (obsolete)
Comment 11 Regina Henschel 2018-09-30 12:05:42 UTC 
The bug still exists in Version: 6.2.0.0.alpha0+ (x64)
Build ID: efe119aaa50e9f532b3fac1ef153469c80f24b80
CPU threads: 8; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-09-10_01:36:26
Locale: de-DE (en_US); Calc: CL
Comment 12 QA Administrators 2019-10-01 03:02:27 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2022-09-12 03:40:15 UTC Comment hidden (obsolete)
Comment 14 QA Administrators 2024-09-12 03:16:39 UTC Comment hidden (obsolete)
Comment 15 Marco Diego Aurélio Mesquita 2024-12-03 16:59:32 UTC 
Bug still happens in 24.8.3.2.