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.
Same here: inheritance is lost on save (but seen after document reopen, which is worst). LibreOffice 3.6.2 Windows 7 x64
I can confirm this behavior on 3.6.3.2 and I can confirm even worse behavior on 4. Marking: 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. https://bugs.freedesktop.org/show_bug.cgi?id=57960 Thanks for reporting!
[Reproducible] with "LibreOffice 3.6.4.3" 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 3.6.4.3 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). @eymux 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>
I already observe the problem with server installation of "LibreOffice 3.5.7.2 rc German UI/Locale [Build-ID: 3215f89-f603614-ab984f2-7348103-1225a5b] on German WIN7 Home Premium (64bit), but not with 3.5.1.2 Bibisect might help?
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 @eymux: Until proof of the opposite I am tending to handle this one as a problem with a damaged document. Your opinion?
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)
Created attachment 71840 [details] INVALID ODF I doubt that we should do fixes to handle any broken document, and so I am tending to see this one WONTFIX
@Michael: 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?
This may be a duplicate of bug 58730 which was fixed in 4.0.0 RC2.
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 ***