Bug 108518 - FILEOPEN: DOC file list numbers incorrectly italicized
Summary: FILEOPEN: DOC file list numbers incorrectly italicized
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: All All
: low minor
Assignee: Justin L
URL:
Whiteboard: target:7.3.0
Keywords: bibisected, bisected, filter:doc, regression
Depends on:
Blocks: DOC-Bullet-Number-Lists
  Show dependency treegraph
 
Reported: 2017-06-14 04:40 UTC by Gabriel Bowater
Modified: 2021-07-23 17:31 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
File with number incorrectly italicized when opened in LibreOffice 5.3.3.2 (31.00 KB, application/msword)
2017-06-14 04:41 UTC, Gabriel Bowater
Details
PDF showing MS Office rendering list numbers plain while LibreOffice renders them in italics (118.87 KB, application/pdf)
2017-06-14 04:42 UTC, Gabriel Bowater
Details
FillableSAP-Trim.doc: OOo bug that breaks with the revert (62.00 KB, application/msword)
2021-03-09 13:49 UTC, Justin L
Details
FillableSAP_mosdump.doc: An MSO_dump - turning binary into (semi)readable code (3.25 MB, application/msword)
2021-03-11 06:34 UTC, Justin L
Details
108518_numberingTest.doc: hand-made testing doc - last size/colour won. (22.50 KB, application/msword)
2021-03-11 08:55 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gabriel Bowater 2017-06-14 04:40:57 UTC
Description:
When opening attached DOCX file in LibreOffice 5.3.3.2 the list numbers are in italics, when in the original document opened in Microsoft Office the numbers are plain. 

Steps to Reproduce:
1. Open attached file
2. Check numbers
3. Numbers are rendered italicized 

Actual Results:  
List numbers are rendered italicized.

Expected Results:
List numbers are rendered plain.


Reproducible: Always

User Profile Reset: No - reported on multiple systems

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Comment 1 Gabriel Bowater 2017-06-14 04:41:47 UTC
Created attachment 134010 [details]
File with number incorrectly italicized when opened in LibreOffice 5.3.3.2
Comment 2 Gabriel Bowater 2017-06-14 04:42:49 UTC
Created attachment 134011 [details]
PDF showing MS Office rendering list numbers plain while LibreOffice renders them in italics
Comment 3 tommy27 2017-06-14 10:02:17 UTC
issue confirmed under Win7 x64 using LibO 5.3.3.2.
status NEW
Comment 4 Telesto 2017-06-14 14:48:20 UTC
Found in
Versie: 4.1.0.4 
Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28

but not in
Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89
Comment 5 Justin L 2017-09-02 19:15:56 UTC
bibisect41max points to commit 1c22545edf9085b9f2656ca92781158b6b123db3
Author:     Jian Hong Cheng
CommitDate: Thu Mar 14 10:08:38 2013 +0100
Fix issue #i119405 [https://bz.apache.org/ooo/show_bug.cgi?id=119405]: Numbering text style changed after importing the *.doc
Comment 6 QA Administrators 2018-11-07 04:02:17 UTC Comment hidden (obsolete)
Comment 7 Roman Kuznetsov 2018-11-07 06:10:16 UTC
still repro in

Version: 6.2.0.0.alpha1+
Build ID: 6896f39ffd8a6c4b32b8f601a6a93678247456bd
CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-11-05_22:40:18
Locale: ru-RU (ru_RU); Calc: threaded
Comment 8 QA Administrators 2019-11-08 03:38:22 UTC Comment hidden (obsolete)
Comment 9 Timur 2020-01-29 15:19:53 UTC
Repro for DOC in LO 7.0+. No repro if DOC saved in MSO as DOCX.
Comment 10 Justin L 2020-04-23 19:23:02 UTC

*** This bug has been marked as a duplicate of bug 79330 ***
Comment 11 Justin L 2021-03-08 07:26:05 UTC
This one also has features similar to bug 68988. I think both of these "duplicate" bugs have multiple problems. So let's keep this one out as a unique bug report since it focuses on the italics problem (and the bold numbering of bug 68988's attachment 85272 [details]).

I'm guessing the problem is in the addition of
    //Ensure the default char fmt is initialized for any level of num ruler if no customized attr

If I understand that right, he is saying that even if there was no formatting specified, let's create a named character format for it. Well, if there was no special formatting, why do we need a charstyle for it? And where is the italic/bold information coming from that is being placed in this charstyle? Just eliminating this section fixes this bug and causes no unit test failures (but doesn't fix the main issues in the "duplicate" bugs). It also helps NOT spamming the character styles.
Comment 12 Justin L 2021-03-09 07:26:42 UTC
If 9037 - italics-in-para-causes-italic-numbered-list.doc is first round-tripped by Word 2003, then it opens up properly. So there might be something a bit wrong or corrupt with this file.
Comment 13 Justin L 2021-03-09 09:36:44 UTC
(In reply to Justin L from comment #5)
> bibisect41max points to commit 1c22545edf9085b9f2656ca92781158b6b123db3
> Author:     Jian Hong Cheng
> CommitDate: Thu Mar 14 10:08:38 2013 +0100
> Fix issue #i119405 [https://bz.apache.org/ooo/show_bug.cgi?id=119405]:
> Numbering text style changed after importing the *.doc

I think the premise of this entire commit is wrong. From what I can see, it is affecting the entire numbering style when one of the paragraphs has CR formatting. Well, that might be fine to affect the numbering for THAT PARAGRAPH based on the CR, but it shouldn't affect the numbering attributes as a whole.

Even worse for "9037 - italics-in-para-causes-italic-numbered-list.doc", it appears that the italics definition is coming from "[Option 1:  New Zealand Customs Service, paragraphs 2.1 – 2.7]". But this isn't even defined in the CR. And yet it seems to be applying the italics to the character style WW8Num1z0 - and so it affects every numbering on level one.

But quite honestly, I can't follow the code at all - even in a debugger. So I have little confidence that I understand what is really happening. But my impression is that this commit is almost entirely wrong, and should be completely reverted (except for the two Ignore functions that are being re-used for layout - which is where this is being handled for DOCX anyway, and possibly even for DOC).
Comment 14 Justin L 2021-03-09 09:47:54 UTC
(In reply to Justin L from comment #13)
> and possibly even for DOC).

Yes, in 2018 Mike K set this compatibility flag for DOC for bug 117923
source/filter/ww8/ww8par.cxx-    m_rDoc.getIDocumentSettingAccess().set(
DocumentSettingId::APPLY_PARAGRAPH_MARK_FORMAT_TO_NUMBERING, true);
Comment 15 Justin L 2021-03-09 13:14:06 UTC
(In reply to Justin L from comment #13)
> I think the premise of this entire commit is wrong. From what I can see, it
> is affecting the entire numbering style when one of the paragraphs has CR
> formatting. Well, that might be fine to affect the numbering for THAT
> PARAGRAPH based on the CR, but it shouldn't affect the numbering attributes
> as a whole.
The guys making that patch knew that.  They document in https://bz.apache.org/ooo/show_bug.cgi?id=119405#c11:

Negative Impact:
Although most common user scenarios can be met by the solution,there are still negative impacts.Because the attributes of paragraph end mark(0x0D) will be set to the character style binding to the given level of a number rule,it will have the global impact..Other paragraphs that are applied with the same number rule's level will also be changed.Please refer to the Test Case 6, the color of the bullet will be changed finally. Generally, MS Word users will have their numbering/bullets the same attributes/style when using the same level's of number rule,correspondingly,the impacted scenarios are rarely.
Comment 16 Justin L 2021-03-09 13:49:30 UTC
Created attachment 170372 [details]
FillableSAP-Trim.doc: OOo bug that breaks with the revert

I reviewed the unit tests in the Apache bugzilla, and C0 and C7 examples are based off of the same document. They both break with the revert.

The rest of the documents look fine.
Comment 17 Justin L 2021-03-11 06:34:05 UTC
Created attachment 170401 [details]
FillableSAP_mosdump.doc: An MSO_dump - turning binary into (semi)readable code

<transformed value="Dredging Project\x0DAssessment Techniques Needed for the Dredging Project \x0D"/>

What I understood from this is that the carriage return at the end of the problematic paragraph is in the MIDDLE of a character run. (This seems slightly unusually, but definitely NOT uncommon.) This run of characters definitely includes the Bold character attribute.
Comment 18 Justin L 2021-03-11 08:55:51 UTC
Created attachment 170405 [details]
108518_numberingTest.doc: hand-made testing doc - last size/colour won.

Proposed fixes:
-https://gerrit.libreoffice.org/c/core/+/112319 tdf#108518 partial revert tdf#64222 sw: better DOCX im/export

And I think waiting until 7.3 will be the actual fix
-https://gerrit.libreoffice.org/c/core/+/112320 tdf#108518 revert OOo hack: Fix issue #i119405: Numbering text style
Comment 19 Commit Notification 2021-03-18 15:40:48 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/0a32371cc2f93fad7954e0fe9c48976aae6c5b9f

tdf#108518 partial revert tdf#64222 sw: better DOCX im/export

It will be available in 7.2.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:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 20 Commit Notification 2021-06-14 08:58:38 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/343d4d32f00053bd72cfe240125835fe25ce264f

tdf#108518 revert OOo hack: Fix issue #i119405: Numbering text style

It will be available in 7.3.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:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 21 Justin L 2021-06-14 09:04:22 UTC
No backporting please - unless you want to handle the fallout yourself.
Comment 22 Xisco Faulí 2021-06-14 09:08:13 UTC
(In reply to Justin L from comment #21)
> No backporting please - unless you want to handle the fallout yourself.

Hi Justin,
even no backporting to 7.2 branch? it was created yesterday...
Comment 23 Telesto 2021-06-14 09:14:42 UTC
(In reply to Xisco Faulí from comment #22)
> (In reply to Justin L from comment #21)
> > No backporting please - unless you want to handle the fallout yourself.
> 
> Hi Justin,
> even no backporting to 7.2 branch? it was created yesterday...

I don't think so . Justin waited for the 7.3 branch point before pushing.. but well answering a question not directed to me.
Comment 24 Justin L 2021-06-14 09:33:42 UTC
(In reply to Xisco Faulí from comment #22)
> even no backporting to 7.2 branch? it was created yesterday...
I know.  See Comment 18.
Comment 25 BogdanB 2021-06-17 12:46:39 UTC
It's ok in
Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: c703b2d22c3f45825d9c9d790c3b5a4b6f97e776
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: ro-RO (ro_RO); UI: en-US
Calc: threaded

Not italic.