Unwanted Paragraph Direct Formatting observed with LO

ISSUE: After upgrading recently from LO to (the current stable version), my documents now display MANY instances of unwanted Paragraph Direct Formatting (ParaDF). This can be viewed using Style Inspector, alternatively the ‘Spotlight’ check-box in the Paragraph style sidebar of LO 7.6 illustrates them graphically (with grey-hatching).
The same documents viewed/edited under 7.3 show NO Paragraph Direct Formatting (checked on another laptop with 7.3).

Note that if a LO 7.3 document being viewed under LO 7.6 is subsequently saved, the ParaDF’s become embedded i.e. are now present even when viewed in LO 7.3.

TO REPLICATE: Create a new document (Ctrl+N) in LO 7.6 and edit a default Paragraph style e.g. ‘List 1’ with ‘Apply List Style’= ‘Numbering A,B,C’, and ‘Next paragraph style’= ‘List 1’. Apply this style to any text typed into the document.

ParaDF is not immediately obvious, however after save/reload ALL instances of ‘List 1’ Paragraph style will now exhibit Paragraph Direct Formatting (a repeat of the associated ‘List Style Name’).

Note: All LO 7.6 test were with a fresh User Profile to avoid any lurking gremlins. Same results with LO Fresh 24.2.

CONCLUSION: I’m concerned about the apparent incompatibility of documents created in LO 7.3 and subsequently used in 7.6.
Although the document formatting looks OK, complications would arise if you apply a different style e.g. ‘Body text’ to any of these paragraphs, as the Direct Formatting remains. This negates the benefit of using styles.

Has anyone else noticed this?
Is it an unintended consequence of other LO changes i.e. possibly a bug?

I’ve also observed the appearance of ‘Heading Numbering’ ParaDFs with LO 7.3 documents opened in 7.6, but haven’t been able to replicate it with documents created/edited solely in

See Bug 142190 - Writer Style Inspector shows list as character direct formatting and not as part of the paragraph style

Thanks for responding. I think Bug 142190 refers to a reporting error in Style Inspector.

I’m concerned with the actual unwanted (duplicate) list Paragraph Direct formatting which appears in addition to a paragraph’s ‘Apply List Style’ setting.

This can be demonstrated by applying an alternative paragraph style e.g. ‘Body Text’ to an affected paragraph. Although the main Paragraph style changes, the unwanted Paragraph Direct Formatting remains (e.g. number/bullet) in effect.

To remove the (erroneous) Paragraph Direct Formatting you need to carry out the following sequence on every affected paragraph:

  1. Apply other desired Para style e.g. ‘Body Text’.
  2. Remove the unwanted List formatting (e.g. F12 for bullets).
    Note bullet or number levels get reset to 1.
  3. Save.

This negates the benefit of using paragraphs styles to easily/quickly change document appearance.

Paragraph style and list style are two independent layers. Changing paragraph style does not disable the list style in effect.

There are two ways to use list styles:

  • one-shot
    This method is somewhat akin to direct formatting (i.e. in the sense that list style is manually added over any paragraph style). It is a weak form of Direct formatting (DF).
    Therefore, the Style Inspector is right when reporting DF (though not precise enough in the fact that only the application is DF, not the entire list configuration).
  • systematic
    The list style is associated to the paragraph style in the Outline & List tab. Whenever you apply the paragraph style, the list style becomes active without the need to manually set it. If you replace the paragraph style by one without associated list style, the paragraph reverts to an ordinary one (without number or bullet).
    Here, the Style Inspector erroneously reports the list style as DF.

No. What you need is more introspection about your format/layout. If some paragraph style is always associated with list attribute, then link the list style to this paragraph style in Outline a List tab.

I consider this is the correct “semantic” way of marking a document. The list attribute is part of the significance/importance/meaning of the paragraph. Then, it is worth to record this attribute in the paragraph style configuration.

You may object that this causes the creation of yet another paragraph style (dedicated to the list) and prevents the addition of a list style over any paragraph style. Yes. But if you design your styles “semantically”, it clarifies the signification of the paragraph and, in the end, makes your formatting maintenante more rigorous and easier.

1 Like

But I did/do use the systematic method and linked the list style to the paragraph style using ‘Outline a List’ tab, as mentioned in the ‘To Replicate’ steps.

This is why I am so concerned about the result - extra (duplicate) Paragraph Direct Formatting.

Did a quick check: The Paragraph DF is clearly a faulty annoucement, but the list style name is correctly reported. I am puzzled by the Character DF with List Id. I can’t guess the source of it.

I remind you that the Style Inspector is “experimental” (even if has been present for many releases now). The explanation is likely to be found in the parse algorithm of the XML or the internal representation. Taking the example of paragraph/character styles, there are “intermediate” style names P12 and T34 which act as internal names both for styles and DF, allowing uniform handling of formatting. We may be in the same “context” and the Style Inspector didn’t “unwrap” these names like it does for paragraph and character.

This is pure guess from mine.

You say: “Did a quick check: The Paragraph DF is clearly a faulty annoucement”
If it’s only a reporting error, why is the actual document formatting being affected as illustrated when trying to apply a different paragraph style?

There are a few “shadowy” corners in LO. In Writer, list and frame styles are in such “dark areas”. It is somteimes very difficult to remove list style application. This is why it is of utmost importance to adhere to a very strict styling approach.

When you hit the “dark corners”, unfortunately you have to live with them.

To remove the list, it suffices to apply a heading style, e.g. press Ctrl+3 and then to apply Body Text (or Text Body) Ctrl+0. But it is not correct and not how earlier versions such as worked. And all the levels reverting to level 1 is a big problem.

I think you should create a bug report, How to Report Bugs in LibreOffice - The Document Foundation Wiki

EarnestAl said “… it suffices to apply a heading style … then to apply Body Text …”

Yes that trick works, thanks for the note.

I’ve raised Bug Bug 159972 and included the loss of Levels concern.

Let’s see what transpires …

1 Like

There is already another bug report for 7.6 which I didn’t find before so I guess you report will become a duplicate:
Bug 159366 - List styles add paragraph direct formatting on loading Writer document

1 Like

In short, the root cause appears to be a regression introduced in LO 7.6 by Bug 114287. We await a resolution.


  • After some discussion here, I raised Bug 159972 “LO 7.6 Creates Duplicate / Unwanted Paragraph Direct Formatting” which detailed the issue, confirming it started with LO 7.6.

  • Subsequently ErnestAl spotted an earlier report Bug 159366 which identified the same/similar issue. A reply in it identified the cause as a regression introduced by Bug 114287 (raised in 6Dec20215) but not implemented until recently in LO 7.6. I’m not clear on the purpose of Bug 114287 but from other Bug reports it references, it may be to do with improving MS Word import compatibility. It has however screwed LO operation!

  • ErnestAl also spotted Ask 102976 “Lists behavior, from Writer v.7.5 to .7.6 and 24.2”. I believe the issue described here is also due to the unwanted Paragraph Direct Formatting introduced in LO 7.6.

  • Documents created originally in <= LO 7.5, become ‘corrupted’ when opened/saved in >= LO 7.6 by the addition/duplication of Paragraph Direct Formatting involving an associated List style. When such documents are subsequently viewed in any LO version this direct formatting is embedded and adversely affects making Style changes. A key concern is how can this embedding be reversed?

  • Anyone concerned/affected by this bug please make your opinions known by replying to Bug 159366 (I’ve made my Bug 159972 a Duplicate of it since it’s further down the line for resolution) or Bug 114287 ?