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: 2022-09-12 03:40 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 
Dear Jim Avera,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug