Bug 133000 - FILEOPEN DOCX Indent of numbered paragraphs based on custom style lost
Summary: FILEOPEN DOCX Indent of numbered paragraphs based on custom style lost
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: All All
: medium normal
Assignee: Justin L
Whiteboard: target:7.0.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: DOCX-Bullet-Number-Outline-Lists
  Show dependency treegraph
Reported: 2020-05-13 11:00 UTC by NISZ LibreOffice Team
Modified: 2020-12-15 08:06 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Example file from Word (13.44 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-05-13 11:00 UTC, NISZ LibreOffice Team
Screenshot of the original document side by side in Word and Writer (120.49 KB, image/png)
2020-05-13 11:00 UTC, NISZ LibreOffice Team

Note You need to log in before you can comment on or make changes to this bug.
Description NISZ LibreOffice Team 2020-05-13 11:00:20 UTC
Created attachment 160748 [details]
Example file from Word

Attached artificial document (improved version of attachment #147857 [details] from bug #122342) has a few numbered paragraphs formatted with custom style and sublevels.
If the paragraphs are in a list of multiple items, the sublevel paragraphs lose their indent. If they are in a single item list, the sublevel paragraphs appear fine.

Steps to reproduce:
    1. Open attached document

Actual results:
Sublevel paragraphs from multiple item lists are not indented from left as in Word.

Expected results:
Same appearance as in Word.

LibreOffice details:
Version: (x64)
Build ID: f9790da286f2d2fa47f1748f8cfa6172c6622ca3
CPU szálak: 4; OS: Windows 6.3 Build 9600; Felületmegjelenítés: Skia/Raster; VCL: win; 
Locale: hu-HU (hu_HU); UI: hu-HU
Calc: CL

Bibisected using bibisect-win64-6.5 to:
URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=35fc5ef0a759884b24ed8b83cd05702a0fab64cc
author	Justin Luth <justin.luth@collabora.com>	2020-04-11 12:05:03 +0300
committer	Miklos Vajna <vmiklos@collabora.com>	2020-04-14 09:46:52 +0200

tdf#131321 writerfilter: ApplyNumberingStyleNameToParaStyles()

Adding CC to: Justin Luth
Comment 1 NISZ LibreOffice Team 2020-05-13 11:00:39 UTC
Created attachment 160749 [details]
Screenshot of the original document side by side in Word and Writer
Comment 2 Xisco Faulí 2020-05-13 12:05:05 UTC
Reproduced in

Build ID: 1ffe59ef31186e36ad0aa7bbcdd32e407ee8d26c
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 3 Xisco Faulí 2020-05-13 12:26:20 UTC Comment hidden (obsolete)
Comment 4 Justin L 2020-05-13 16:22:10 UTC
Notice that it is only indenting that is wrong - the numbering itself is correct (as described in Comment 0, but I just want to emphasize that). Also, this only affects WWNum1, and if those lines are selected, changed to WWNum2, and then back to WWNum1, then the indenting is correct. So the problem is somewhere with direct formatting.

My patch had nothing to do with indenting, so this must have exposed some other problem.  (Oh great.) Prior to my patch, CustomStyle had no idea that it was specifying a numbering. Now it shows that it is connected to WWNum1, and applies the numbering to new paragraphs that are marked as CustomStyle - like it should.

It looks like the Style's indenting is being (dynamically - as a style) applied INSTEAD OF the numbering's indenting on the sublevels. In other words, the sublevels must not be splattering direct formatting onto the paragraph itself like they normally do.
<w:style w:type="paragraph" w:customStyle="1" w:styleId="CustomStyle">
<w:name w:val="CustomStyle"/>
      <w:numId w:val="1"/>
    <w:ind w:left="714" w:hanging="357"/>
Comment 5 Justin L 2020-05-14 10:22:20 UTC
Adding Vasily to CC, since he has recently done lots of work here, and should at least be aware of other work happening in numbering.

I'm am guessing that RES_PARATR_NUMRULES is being swallowed up because the paragraph style specifies the same list - so the direct formatting is lost. [Turn off numbering style in CustomStyle paragraph style - the sublevels (which had direct list formatting) are no longer numbered, but the first level (which inherited from the style) are still numbered. Go figure.]

There is something funny about the way that the numbering is applied, because if you simply remove and re-add WWNum1 to CustomStyle numbering, then it looks fine.

The problem does NOT seem to be with direct formatting of indenting, because changing the indenting of CustomStyle affects the indenting of the sublevels - indicating that they are inheriting. So for some reason, the paragraph style overrides the numbering formatting, even though Writer supposedly prioritizes the list-style over the para-style. [probably because the list-style itself is not actually applied, just one specific numbering?]

This "hack" fixes the problem for this specific document.
    if( !IsStyleSheetImport() )
        uno::Any aRules = uno::makeAny( pList->GetNumberingRules( ) );
        rContext->Insert( PROP_NUMBERING_RULES, aRules );
+       rContext->Insert( PROP_NUMBERING_STYLE_NAME, pList->GetStyleName());
Comment 6 Justin L 2020-05-16 19:00:37 UTC
proposed fix at https://gerrit.libreoffice.org/c/core/+/94365.

Probably it would be better to find the root cause in SW, but doing it this way also takes care of the "swallowing up of the numbering rule" problem that I noted in comment 5. Now that the style is hard-coded, it isn't lost if the para-style changes its numbering.
Comment 7 Commit Notification 2020-05-25 04:44:42 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":


tdf#133000 writerfilter: apply non-contradictory num-style

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.