# Styles don't work

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 ...

edit retag close merge delete

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. ( 2019-08-21 19:26:32 +0200 )edit 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 ...(more) ( 2019-08-22 08:01:25 +0200 )edit 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 ...(more) ( 2019-08-22 16:07:38 +0200 )edit ## 2 Answers Sort by » oldest newest most voted 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!

more

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.

C:\fakepath\test.docx

more

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.

( 2019-08-21 20:22:39 +0200 )edit