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 treegraph
 
Reported: 2014-01-14 07:41 UTC by Jim Avera
Modified: 2018-09-30 12:05 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

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