Styles don't work

[ksltd]

I have a suite of existing word documents in .docx format. They are medium size 25-100 pages each. I would like to maintain the documents using LibraOffice rather than word. I am running 6.1.0.3 on MacOS 10.10.5. Here’s my dose of drama using LibreOffice:

I open the document using LibraOffice, select the entire contents and choose Format → Clear Direct Formatting
I select Styles → New Style and create a style with Inherit From set to “-None-”
I set the font and I adjust Spacing Below Paragraph to from 0.08 0.00 and save the new style
I select a row in a table and using the toolbar pulldown, choose my new style for this row
Everything works as expected!
I save the document and close the file.
I reopen the file
The table row has 0.08" trailing vertical space inside the boxes!
I select the row and choose Format → Paragraph.
The trailing space is parameter is set to 0.08".
I use the toolbar to see the style and choose Edit Style - the style trailing space is 0.00"
With the row still selected, I choose Format → Clear Direct Formatting
The row updates to have 0.00" of trailing space
I save the document and reopen it
The 0.08" of trailing space is back again

Questions:
Why does saving and reopening my document cause its formatting to change, ever?
How do I get the paragraph trailing space for a custom style to be 0.00 and to apply to selected text?

Thank you

You say you saved the file as a docx and the problem went away. The file was a .docx file and when I repair the formatting and save it as a docx file, the problem comes back. Are you saving with “Save” or with “Save As”? I have tried both and the problem always comes back after saving, closing and re-opening. How is this different for you than for me? Any thoughts?

Regarding native file formats - I understand this problem very, very well. However, the face of Libreoffice suggests that Libreoffice is a suitable replacement for Word. Without getting into endless philosophy, I don’t understand this positioning when I can’t open, edit, save a fairly typical engineering document (numbered paragraphs, table & cross-reference intensive).

If I maintain the document in ODF format, I have dozens of hours of work to do to get that format to work as Libreoffice doesn’t do the conversation successfully. If I maintain it in docx format, it seems I can’t use Libreoffice unless we can sort out some approach to resolving these formatting issues.

Are you suggesting I use Word to save it in ODF format and then edit with Libreoffice?

Ok, so when you said that saving as .docx solved the problem, you meant .odt. Got it.

When I save the file as .odt, you are right, the one row in question no longers gets the 0.08" of trailing white space. However, the entire table formatting is destroyed - not messed up, destroyed - to the point where reconstituting them means deleting and recreating them. A big price to pay to remove a little white space.

Interestingly, if I open and save as a .docx, which gains the 0.08" of whitespace and then I open in Word, select the table, choose Format → Paragraph and reduce the whitespace to 0pt, save, open with Libreoffice and the problem does not recur.

Libreoffice can read, render, modify and save these tables perfectly well when starting and ending in .docx format. I trust it can read, render, modify and save them perfectly well when starting and ending in .odt format.

So now there seems to be two bugs:

1. Libreoffice seems intent on decorating a given paragraph style with an extra 0.08" of white space for no discernible reason yet Microsoft Word can be used to fix this
2. Libreoffice does not correctly save tables in .odt format when they were read in .docx format

While I do truly appreciate the challenges of document format interchange, based on these symptoms, this doesn’t appear to be that kind of problem.

Is there any possibility of someone improving these two situations?

[ajlittoz]

Can’t reproduce here. When I Clear formatting from the toolbar paragraph style menu, the style for the row is reset to Default Style. It does not apply the new definition of your custom style. If I use Format>Clear Direct Formatting, nothing happens because changing a style is not direct formatting. You should have reapplied the style instead.

Edit your question to better describe your procedure (don’t use an answer reserved for solutions) or attach a sample document with the problem.

Also, saving a document in a non-native format leads reliably to future problems. docx is known to suffer severe problems and ODF is not a clone of docx. If you switch from M$ Word to LO Writer, switch also format.

[ajlittoz]

Big, big, big apologies. My fingers and my mind slipped. I really meant .odt. I proof-read my answer but this was so obvious (for me in my head) that I didn’t see this blunder!

Without entering into details, difficulties arise on features not existing in Word but present in Writer, e.g. on character and list styles. The equivalent artifacts in Word are translated as direct formatting in Writer. Similarly, direct formatting on paragraphs (resulting in “anonymous” Word styles) result in many single-usage paragraph styles with weird names.

Regarding the conversion task, ideally, documents should be linked to a template. Unfortunately, this can’t be done easily afterwards.However, you can design your own set of consistent style family (don’t forget the page and list ones) for the first document. When you need to edit another one, you begin the process by importing the style from the first. Progressively, your docs get converted.

[ajlittoz]

If you start from a well-defined .docx document, matters are rather simple: Writer only has to “read in” the stuff and make simple conversions to ODF concepts. When you start to edit the document, you add an extra conversion ODF → docx (which is approximative due to the closed nature of docx). Then, upon next read, you must again revert this conversion. Alas, the round trip is not “idempotent”, the mapping between ODF and docx is not a bijection, consequently the exact inverse function does not exist.

If document interchange is of prime interest for you, .doc is known to work better. But, there is no free meal: .doc being an older format does not contain all features of .docx. It does not matter until you use the newer features, but I can’t tell you which are which.

The main problem is Word has a less mature notion of styles. Consequently, many added decorations appear to Writer as “direct formatting” which is the source of evil.

[ksltd]

Hi,
I’ve just upgraded to 6.2.5.2, which does exactly as I described above.
I’ve reproduced with a one page (16kb) document, and that’s attached here.

If you focus on the table heading, you’ll see the trailing white space in the first row of boxes. If you simply re-apply the style already applied “My Table Heading”, that whitespace will disappear. Save the file and reopen and the white space comes back.

When I save my document as in .ODT format, the formatting is obliterated. Tables and outline-style paragraph headings become unintelligible. You can see this with the test document here, also. Once saved and reopened, the table bears no resemblance to the original.

test.docx

[ajlittoz]

This is not a “solution”. Please transfer it into your question (you can reopen your question for update with the edit link). This no-answer makes users believe that the problem is solved when you look only at the list of question. This is a source of confusion and frustration.

I’ll have a look at the file.

[ajlittoz]

This is a typical problem of compatibility between ODF and .docx standards.

If I save your file as .odt, the problem vanishes.

IMHO, the cause is the difference of management of tables. I’ve always experienced bad results with tables exported to .doc(x). Word has a less developed system of styles than Writer. When you encapsulate that in a table, Writer has to translate the table description and content in Word primitives, and this is approximative in some areas. Then, when you reload the file, an “inverse” conversion occurs again. Now, the approximation must be understood and interpreted in terms of ODF primitives. A new approximation is applied as direct formatting. This is why Format>Clear Direct Formatting works while it should not in pure style context.

The lesson is the golden rule: in any application, use the native format to store your file. Only at the end of the process, you may export the result to a foreign format to send the file to one who can’t absolutely read .odt. But attach also a .pdf for reference.

Officially, Word knows how to read and manage ODF files because M$ committed to support this format. However, first thing they did is to add diverging features and to misinterpret the standard!

To show the community your question has been answered, click the ✓ next to the correct answer, and “upvote” by clicking on the ^ arrow of any helpful answers. These are the mechanisms for communicating the quality of the Q&A on this site. Thanks!