Bug 95377 - DOCX: Numbering lost from paragraph styles on import
Summary: DOCX: Numbering lost from paragraph styles on import
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.1.1 rc
Hardware: All All
: medium minor
Assignee: Justin L
URL:
Whiteboard: interoperability target:6.1.0
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks:
 
Reported: 2015-10-28 02:48 UTC by Matthew Holloway
Modified: 2018-05-10 14:56 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Example document (27.82 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2015-10-28 02:48 UTC, Matthew Holloway
Details
How LibreOffice 4.3.0.4 renders the document (67.44 KB, image/png)
2015-10-28 02:49 UTC, Matthew Holloway
Details
How LibreOffice 4.3.1.1 renders the document (69.59 KB, image/png)
2015-10-28 02:50 UTC, Matthew Holloway
Details
correct word with numbering and LO with no numbering (296.03 KB, image/png)
2015-10-28 10:06 UTC, steve -_-
Details
tdf95377_parastyleNumbering.docx: MSWord 2003 created document with paragraph numbering on style (10.99 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-01-16 10:05 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Holloway 2015-10-28 02:48:10 UTC
Created attachment 120031 [details]
Example document

In the attached document paragraphs are numbered in LibreOffice 4.3.0.4, but the numbers are gone in LibreOffice 4.3.1.1 and later (to 5.0.2.2)
Comment 1 Matthew Holloway 2015-10-28 02:49:24 UTC
Created attachment 120032 [details]
How LibreOffice 4.3.0.4 renders the document
Comment 2 Matthew Holloway 2015-10-28 02:50:53 UTC
Created attachment 120033 [details]
How LibreOffice 4.3.1.1 renders the document
Comment 3 steve -_- 2015-10-28 10:05:50 UTC
Confirmed on osx

Comparing LO master + word of sample file
Comment 4 steve -_- 2015-10-28 10:06:22 UTC
Created attachment 120038 [details]
correct word with numbering and LO with no numbering
Comment 5 Matthew Holloway 2015-11-16 22:50:43 UTC
Bug still present in the 5.1 alpha
Comment 6 Joel Madero 2015-12-14 01:55:25 UTC
Bibisected and downing severity (minor - can slow down but will not prevent high quality work)

7ccda96816d4ec20bdfe90cb51446ffdafcbf3e3 is the first bad commit
commit 7ccda96816d4ec20bdfe90cb51446ffdafcbf3e3
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Sat Mar 14 21:16:39 2015 +0800

    source-hash-e49d2b31fb2020d065b4ad940d1031d07b10f32b
    
    commit e49d2b31fb2020d065b4ad940d1031d07b10f32b
    Author:     Vinaya Mandke <vinaya.mandke@synerzip.com>
    AuthorDate: Fri Jun 6 14:12:48 2014 +0530
    Commit:     Miklos Vajna <vmiklos@collabora.co.uk>
    CommitDate: Tue Jun 10 09:57:45 2014 +0200
    
        fdo#78939 [DOCX] Hang while opening due to incorrect modification of Style
    
        http://opengrok.libreoffice.org/xref/core/sw/source/core/unocore/unosett.cxx#1884
        Modifies the refernced style of the numbering rule to use the current numbering rule.
        Actually the refernced style is not supposed to be modified.
        As the numbering level formatonly uses that properties particular style,
        which may or may not be a numbering style
    
        For this Particular document the numbering format refers the "Default Style" (Normal).
        Almost all of the styles in style.xml are based on it. Normal was modified,
        and as a result the whole document was bulletized; Which caused the hang while opening
    
        Removed the addition of style as a PARA_STYLE, as the properties of the
        refernced style are already added in ListLevel::AddParaProperties
    
        Conflicts:
        	sw/qa/extras/ooxmlimport/ooxmlimport.cxx
    
        Reviewed on:
        	https://gerrit.libreoffice.org/9668
    
        Change-Id: I8cc143805a38613908d2e2cb4827882d4cf40a78

:040000 040000 f8a003dd473173a2e0e613a752bad9082ddb65a9 af086c401b0210b24f67802add7590f0865976d2 M	opt


# bad: [cf6ea17155fabb2a120ba07c150735591ac861d7] source-hash-3f94c9e9ddfd807b449f3bb9b232cf2041fa12d2
# good: [fc71ac001f16209654d15ef8c1c4018aa55769f5] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
git bisect start 'latest' 'oldest'
# bad: [8cf60cc706948588e2f33a6d98b7c55d454e362a] source-hash-f340f0454627939f1830826fb5cc53a90e6c62a4
git bisect bad 8cf60cc706948588e2f33a6d98b7c55d454e362a
# bad: [d9885f526fc7a09cc8f9f8ee643af1b966be24bb] source-hash-d1465c64c6f64ad8dd25e40cdc69649b24b305ea
git bisect bad d9885f526fc7a09cc8f9f8ee643af1b966be24bb
# good: [e3eab511ffbcd2e1e2c67e7a4fec162bb0b26b7a] source-hash-dc9cc46f3223aff3f85d3ce9696178a5f4d3d087
git bisect good e3eab511ffbcd2e1e2c67e7a4fec162bb0b26b7a
# bad: [1477f347fb61b5b07de64312247b49371812f5b4] source-hash-4598bbe41d0906a34ceb1126c7fce2108642cd8e
git bisect bad 1477f347fb61b5b07de64312247b49371812f5b4
# bad: [1d06fc5290d00a6477d3b4797d3f000fd5ff654b] source-hash-c44c569aeba043fad7ed1a3b7e676d9cde79bfb1
git bisect bad 1d06fc5290d00a6477d3b4797d3f000fd5ff654b
# good: [58faafa76aaf00296e7a7a92be8fcf85194472f1] source-hash-f18548eb689d9e5effe0ab7c01639b4d13e2f14d
git bisect good 58faafa76aaf00296e7a7a92be8fcf85194472f1
# bad: [5b4629729c8c88b5040b1239b8255c23d0d5a079] source-hash-a72ea67d52bf083034756332bf5f7e5c1c416129
git bisect bad 5b4629729c8c88b5040b1239b8255c23d0d5a079
# good: [31eff63a578f47509f6d440420d8528320c789cc] source-hash-bcca34ed26d82cc79b796ae16ef946fc13f0b1cf
git bisect good 31eff63a578f47509f6d440420d8528320c789cc
# good: [3158bfc57794d806c23f8a62b3dcdeeb89c995a7] source-hash-f517362fb6df839e9d1f828b286e1709cbbbe235
git bisect good 3158bfc57794d806c23f8a62b3dcdeeb89c995a7
# good: [b8ca1579af09f08f5e4cc7556342ef081770c910] source-hash-64992cc56e0e8a480e33b847d3a327f8229535d2
git bisect good b8ca1579af09f08f5e4cc7556342ef081770c910
# good: [19a8e2698909e1da59ba21faf0af244cd837db6d] source-hash-32ac015be4d0f33120bc066e7f49e197c7405c45
git bisect good 19a8e2698909e1da59ba21faf0af244cd837db6d
# bad: [7ccda96816d4ec20bdfe90cb51446ffdafcbf3e3] source-hash-e49d2b31fb2020d065b4ad940d1031d07b10f32b
git bisect bad 7ccda96816d4ec20bdfe90cb51446ffdafcbf3e3
# good: [4749b6cccaebf45437fcabf867a77e1cdcf9efc4] source-hash-f3160a7effe70f10c669b085c840bfc77b8ef671
git bisect good 4749b6cccaebf45437fcabf867a77e1cdcf9efc4
# first bad commit: [7ccda96816d4ec20bdfe90cb51446ffdafcbf3e3] source-hash-e49d2b31fb2020d065b4ad940d1031d07b10f32b
Comment 7 Aron Budea 2016-08-31 04:37:39 UTC
First bad commit verified, adding bisected keyword. Bug still present in v5.2.1.2.
Vinaya, can you please take a look?
Comment 8 Xisco Faulí 2016-09-24 14:54:26 UTC

*** This bug has been marked as a duplicate of bug 87052 ***
Comment 9 Justin L 2018-01-12 16:00:36 UTC
not a duplicate
Comment 10 Justin L 2018-01-16 10:05:53 UTC
Created attachment 139122 [details]
tdf95377_parastyleNumbering.docx: MSWord 2003 created document with paragraph numbering on style

This is rather amazing.  On import, the numbering is generally applied to each paragraph, but it is lost from the style itself. So, any paragraph that later has the style applied will not be part of any numbering.

In this simplified example, the normal (default) style has numbering applied. The body style of course inherits that setting. In LO, the import recognizes that normal has numbering enabled, but it only affects the inheriting styles, and not the default style. So, only the second paragraph shows numbering.

Since "default style" is assumed, the logic for LN_CT_PPrBase_pStyle is never called and so the normal convention of "if ListId set on paragraph properties then insert PROP_NUMBERING_STYLE_NAME into this paragraph's properties" is never applied.
Comment 11 Justin L 2018-01-25 17:56:40 UTC
A bold foray into this dangerous area has resulted in these preparatory commits:

writerfilter: use WW8 name for StyleId (Commit 9dfd46ef4b341a5dfed7d320696959402a549fdb)

ooxmlimport: support inherited listid (Commit
8fd13c356d78fb72ba5dd288a495551f23e15363)

with the final piece proposed at https://gerrit.libreoffice.org/#/c/48458/
Comment 12 Commit Notification 2018-01-26 11:42:33 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cc1c9c7484d97167021301f32c3397124c4d79f5

tdf#95377 ooxmlimport: treat default style like named styles

It will be available in 6.1.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 13 Justin L 2018-01-30 04:40:13 UTC
Another important preparatory commit was:
writerfilter: move TopContextType==Para requirement

This is prep work for tdf#95377. I need this function to
run when there is no TopContext. ... However, to avoid causing a regression, I'm just pulling this test into the calling functions. (Of the three instances
calling this function, two need to be contextless..) So, this is not truly NFC because if the followup patch is reverted, then this one will cause a change.

Commit 254c80037a3939c110d5c66fef6c28caf47625e5
Comment 14 Justin L 2018-05-10 14:56:27 UTC
bug 117504 was raised as a regression caused by the fix in comment 12.

> So if this causes any regressions, it ought to just be related to either
> applying later on (at finishparagraph instead of LN_CT_PPrBase_pStyle
> or because it includes the default style.
This one falls under "applying later", and "exposes existing problems" IMHO.