Bug 54627 - FILESAVE FILEOPEN: Style inheritance broken after saving OOo 3.2.1 document
Summary: FILESAVE FILEOPEN: Style inheritance broken after saving OOo 3.2.1 document
Status: RESOLVED DUPLICATE of bug 58730
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) All
: low enhancement
Assignee: Not Assigned
Whiteboard: lhm-limux
Keywords: regression
Depends on:
Reported: 2012-09-07 08:14 UTC by eymux
Modified: 2013-02-11 13:15 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Testdocument created in OOo 3.2.1 (51.08 KB, application/vnd.oasis.opendocument.text)
2012-09-07 08:14 UTC, eymux
INVALID ODF (14.46 KB, application/vnd.oasis.opendocument.text)
2012-12-20 06:39 UTC, Rainer Bielefeld Retired

Note You need to log in before you can comment on or make changes to this bug.
Description eymux 2012-09-07 08:14:57 UTC
Created attachment 66768 [details]
Testdocument created in OOo 3.2.1

When saving and reloading the attached document (created in OOo 3.2.1) with LO, the paragraph formats 'Above paragraph' and 'Below paragraph' in the style 'Heading 2' are set to 0.0. 'Heading 2' should inherit these settings from 'Heading'. The other styles are unaffected.

Steps to reproduce:
* Open test.odt
* Open the paragraph style 'Heading 2'. In 'Indents & Spacing' 'Above paragraph' has the value 0.42cm, 'Below paragraph' has the value 0.21cm. (If you're using non-metric units the values will be different.)
* Note the position of the image
* Save the document under a different name
* Reload the document
* The position of the image has changed
* The value of 'Above paragraph' and 'Below paragraph' are now 0.0cm.

I wasn't able to reproduce this bug with other OOo 3.2.1 documents. So this might be a one time fluke. But since we have thousands of legacy documents, I find this bug somewhat troublesome.
Comment 1 nicorac 2012-10-09 20:43:01 UTC
Same here: inheritance is lost on save (but seen after document reopen, which is worst).

LibreOffice 3.6.2
Windows 7 x64
Comment 2 Joel Madero 2012-12-06 22:18:27 UTC
I can confirm this behavior on and I can confirm even worse behavior on 4. 

New (Confirmed)
Normal (Can prevent high quality work, even with our own format, across OOo and LibO and within LibO)
Highest (line spacing is used commonly, this can make a very serious problem for users)

I also opened another bug to show what I'm seeing with this document. 


Thanks for reporting!
Comment 3 Rainer Bielefeld Retired 2012-12-10 10:57:07 UTC
[Reproducible] with "LibreOffice" German UI/ German Locale [Build-ID: 2ef5aff] {pull date 2012-11-28} on German WIN7 Home Premium (64bit). Tricky thing, and really FILESAVE/FILEOPEN. The problem is the style "Heading 2", what should have "space above/below", but does not have after save / reopen

I will need some moments to think about that. Might have to do with Style + local formatting of paragraph? Can someone create a sample from the scratch ?

1. Document opens fine with
2. Filesave as test3643, close and reopen:
   Bug: Yellow background headings at wrong place
   The prorlem is the style "Heading 2", what should have "spacee above/below", 
   but does not have after save / reopen (check in styles and format paragraph)
3. Close document and open with LibO 333
   Now all is it it's correct place, and headings have correct space above/below

Only for the sake of completeness: different to words in original report the picture is at the correct place (it's anchored to page), but the yellow background headings are at the wrong vertical position (at least for me with WIN).

We need some explications concerning "lhm-limux".
- Who might add that whiteboard key word?
- What consequences should it
  - who should take
  - special Proceeding for QA / devs?
  - anything else?

It could be great if you could complete our hints on <http://wiki.documentfoundation.org/BugReport_Details>
Comment 4 Rainer Bielefeld Retired 2012-12-10 11:23:01 UTC
I already observe the problem with  server installation of "LibreOffice rc German UI/Locale [Build-ID: 3215f89-f603614-ab984f2-7348103-1225a5b] on German WIN7 Home Premium (64bit), but not with

Bibisect might help?
Comment 5 Rainer Bielefeld Retired 2012-12-10 16:19:52 UTC
Similar problems with reporter's sample with AOOo 3.4.1

Looks even worse in “Lotus Symphony Release 3.0.1 Revision 20120110.2000” on German WIN7 Home Premium (64bit) 

I failed (like reporter) to created a document showing the problems from the scratch.

Cyclone and Officeotron Validator rates the document as INVALID
Until proof of the opposite I am tending to handle this one as a problem with a damaged document. Your opinion?
Comment 6 ulkitz 2012-12-14 15:22:13 UTC
You're right it seems to be nearly impossible to create a document with the same behaviour - I even removed any content from the document, saved it, added one heading 1 and one heading2, and everything worked fine. 
But the problem here still is, that it is a document which was created with OpenOffice, and now can't be further edited by LibreOffice. And I don't think we can tell our users here to remove any content, save the document, and then insert the text again. Especially, as the error isn't too obvious, but is visible only after you save and reload your document.
(btw, eymux has left our department and probably won't track this bug any more, I'm one of his successors here)
Comment 7 Rainer Bielefeld Retired 2012-12-20 06:39:15 UTC
Created attachment 71840 [details]

I doubt that we should do fixes to handle any broken document, and so I am tending to see this one WONTFIX
Comment 8 Rainer Bielefeld Retired 2012-12-20 06:48:08 UTC
Reporter's sample is a cruelly broken document (see att. 2012-12-20 06:39 UTC, Rainer Bielefeld with validation results)

But of course it is strange that LibO opens the document and shows contents as expected (penguin between the yellow headins), but then breaks formatting ("forgets" space above/below headings) when LibO saves the document.

Can you please decide whether there is some necessity to improve LibO's "broken document tolerance"?
And/or may be you can leave a hint how reporter can run a batch to repair his documents?
Comment 9 David 2013-02-07 13:39:29 UTC
This may be a duplicate of bug 58730 which was fixed in 4.0.0 RC2.
Comment 10 Michael Stahl (allotropia) 2013-02-11 13:15:08 UTC
indeed another instance of the fo:margin="100%" regression inherited from OOo 3.4 beta

since there won't be another 3.5 release maybe good to lobby your distro to include the fix (it's already in Fedora 17).

technically the document is invalid because of
"element "manifest:manifest" is missing "version" attribute"

but that attribute was not written by any OOo version before OOo 3.4 beta,
(hence all ODF 1.2 documents written by older versions are trivially invalid)
and has nothing to do with the problem.

*** This bug has been marked as a duplicate of bug 58730 ***