Download it now!
Bug 77797 - FILEOPEN: DOCX - Numbering list style not displayed correctly as not pulling in paragraph run properties
Summary: FILEOPEN: DOCX - Numbering list style not displayed correctly as not pulling ...
Status: RESOLVED DUPLICATE of bug 64222
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.0.alpha0+ Master
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
Depends on:
Blocks: DOCX-Bullet-Number-Outline-Lists
  Show dependency treegraph
 
Reported: 2014-04-23 07:19 UTC by Yousuf Philips (jay) (retired)
Modified: 2019-09-10 21:52 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
shows now the numerals are displayed in word viewer (top) and libO (bottom) (24.31 KB, image/jpeg)
2014-04-23 07:19 UTC, Yousuf Philips (jay) (retired)
Details
Word 2013 left, LibreOffice right (31.57 KB, image/png)
2014-04-26 13:26 UTC, Jorendc
Details
4.2.5 VS 4.3.0 (204.15 KB, image/png)
2014-07-05 22:48 UTC, Yousuf Philips (jay) (retired)
Details
file with bold number list (126.41 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2014-07-13 12:50 UTC, Yousuf Philips (jay) (retired)
Details
Sample docx file with numbering displaying differently (13.44 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2015-07-08 18:43 UTC, chuck.pobanz
Details
Compare LO versions and MS (124.25 KB, image/jpeg)
2015-07-09 17:52 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2014-04-23 07:19:27 UTC
Created attachment 97808 [details]
shows now the numerals are displayed in word viewer (top) and libO (bottom)

I downloaded the .docx file found at < http://download.microsoft.com/documents/rus/microsoft4you/How_to_license_the_operating_system_Windows_8_new.docx > and noticed that the numerals of the number list found on page 2 didnt retain their formatting. The strange thing is that if i save the file as a .odt and then reopen the .odt, the formatting will then be displayed.
Comment 1 Jorendc 2014-04-26 13:25:46 UTC
Reproducible, tested using Windows 8.1 with LibreOffice Version: 4.3.0.0.alpha1+
Build ID: f4a6837025a293312cbc43b9c527851362f11030
TinderBox: Win-x86@47-TDF, Branch:MASTER, Time: 2014-04-26_09:21:18

There might be some dupes around. Can't find them right now. But lets mark this as NEW right away.

Kind regards,
Joren
Comment 2 Jorendc 2014-04-26 13:26:06 UTC
Created attachment 98033 [details]
Word 2013 left, LibreOffice right
Comment 3 Owen Genat (retired) 2014-07-05 14:39:31 UTC
This report (opening a DOCX) would seem related to bug 49785 (save ODT as DOCX). Opening the document linked in comment 0 under GNU/Linux highlights an improvement in the handling of the second main heading in recent versions:

- v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a and v4.2.5.2 Build ID: 61cb170a04bb1f12e77c884eab9192be736ec5f5 both render the problem as shown in attachments.
- v4.3.0.2 Build ID: 14ed55896fdfcb93ff437b85c4f3e1923d2b1409 renders the identifier as expected.
Comment 4 Yousuf Philips (jay) (retired) 2014-07-05 22:48:35 UTC
Created attachment 102312 [details]
4.2.5 VS 4.3.0

Yes if you take just the numbered list entry 2 on page 6, it looks like its fine in 4.3.0, but if you take the numbered list entry 1 on page 2, you will see it in bold when its not supposed to be. Also noticed that bullet points that were purple in 4.2.5 are now gray in 4.3.0 (bug 80961).
Comment 5 Owen Genat (retired) 2014-07-08 06:47:48 UTC
(In reply to comment #4)
> but if you take the numbered list entry 1 on page 2, you will
> see it in bold when its not supposed to be. 

Here is a bit more information on this. The XML for list item #1 (page 2) is:

<w:p w:rsidR="0054188B" w:rsidRPr="0054188B" w:rsidRDefault="0054188B" w:rsidP="0054188B">
   <w:pPr>
      <w:keepNext/>
      <w:numPr>
         <w:ilvl w:val="0"/>
         <w:numId w:val="16"/>
      </w:numPr>
      <w:spacing w:before="480" w:after="160" w:line="420" w:lineRule="exact"/>
      <w:outlineLvl w:val="0"/>
      <w:rPr>
         <w:rFonts w:ascii="Segoe UI Light" w:eastAsia="Times New Roman" w:hAnsi="Segoe UI Light" w:cs="Times New Roman"/>
         <w:b/>
         <w:bCs/>
         <w:color w:val="68217A"/>
         <w:kern w:val="36"/>
         <w:sz w:val="36"/>
         <w:szCs w:val="20"/>
         <w:lang w:val="ru-RU"/>
      </w:rPr>
   </w:pPr>
   <w:r w:rsidRPr="0054188B">
      <w:rPr>
         <w:rFonts w:ascii="Segoe UI Light" w:eastAsia="Times New Roman" w:hAnsi="Segoe UI Light" w:cs="Times New Roman"/>
         <w:bCs/>
         <w:color w:val="68217A"/>
         <w:kern w:val="36"/>
         <w:sz w:val="36"/>
         <w:szCs w:val="20"/>
         <w:lang w:val="ru-RU"/>
      </w:rPr>
      <w:t>Выбор лицензии операционной системы Windows 8</w:t>
   </w:r>
</w:p>

The w:b (Bold) element in the first run properties (w:rPr) definition for the paragraph properties (w:pPr) is likely the reason why the identifier in this case is displaying in bold. The w:bCs (Complex Script Bold) elements do not apply as Cyrillic (U+0400-04FF) is in the High ANSI, rather than Complex Script, font group, under OOXML. 

The next identical-level list item (#2) on page 6 of the document does not have this bold element definition in the XML. The example in ISO/IEC 29500:2012, §17.3.2.7, p.273 tends to indicate that a bold rendering in the case of list item #1 (page 2) is accurate.

> Also noticed that bullet points that were purple in 4.2.5 
> are now gray in 4.3.0 (bug 80961).

This appears to be much the same issue i.e., they are now being rendered as defined in the XML. I will respond separately in that bug. 

Both these issues appear to illustrate that no currently available version of MS Office is compliant with (i.e., interprets correctly) OOXML Strict. What MS Word renders on screen cannot be taken as "correct". Only what is defined in ISO/IEC 29500 is correct, and even that is open to interpretation.
Comment 6 Owen Genat (retired) 2014-07-13 07:27:35 UTC
Jay, it is possible that my prior analysis (comment 5) of the bold list identifier merely indicates why it is now appearing in bold (the <w:b/> element). The underlying reason though may actually be a regression in handling the overriding character style (if there is one) for this identifier, as indicated by Michael Stahl in bug 80961. In this case I can't locate a corresponding character style.

Despite what it looks like I am actually trying to help, although I am not always correct. Apologies if this is the case here.
Comment 7 Yousuf Philips (jay) (retired) 2014-07-13 12:50:19 UTC
Created attachment 102698 [details]
file with bold number list

Owen, no need for apologize as we are all trying to make LibO better and sometimes we arent able to fully get our messages across when we type. :)

I did some more checking and both Kingsoft Writer and Calligra Words show it in non-bold. I opened the file in word 2013 and selected the number list and added bold to it, which does effect both number list entries, and have attached it. Hopefully this will make it easier to figure out.
Comment 8 Owen Genat (retired) 2014-07-15 05:36:12 UTC
(In reply to comment #7)
> I opened the file in word 2013 and selected the number list and
> added bold to it, which does effect both number list entries, and have
> attached it. Hopefully this will make it easier to figure out.

Thanks Jay. The key change seems to be this diff in word/numbering.xml:

1378c1378,1379
<         <w:b w:val="0"/>
---
>         <w:b/>
>         <w:bCs w:val="0"/>

Line numbers 1378-79 indicate <w:abstractNum w:abstractNumId="20"> which I believe is a character style, although of a different type?
Comment 9 chuck.pobanz 2015-07-08 18:43:21 UTC
Created attachment 117135 [details]
Sample docx file with numbering displaying differently

I don't know if this is the same issue or not, but here is a sample document with numbering that is displayed differently (look especially at font size for last 'A' and 'B'). 
'Microsoft Office 2013' on Windows 8 
'LibreOffice 4.4.4.3' on Ubuntu 14.04.
Comment 10 Timur 2015-07-09 17:52:55 UTC
Created attachment 117163 [details]
Compare LO versions and MS

Comparing diff. LO versions and MS I conclude that the original bug reported for LO 4.2.3 (small and black) looked better (was fixed?) in 4.2.6 (proper color and size), like MS, and then it went for worse in 4.3 (black) and even more worse now (black and bold).
Comment 11 QA Administrators 2016-09-20 10:14:03 UTC Comment hidden (obsolete)
Comment 12 Telesto 2016-12-07 13:15:28 UTC
Still reproducible with:
Version: 5.4.0.0.alpha0+
Build ID: a9f56091b6422ec8c42f09b8472200ae4ab12548
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-12-05_23:12:26
Locale: nl-NL (nl_NL); Calc: CL
Comment 13 Yousuf Philips (jay) (retired) 2017-09-27 09:13:26 UTC
(In reply to Owen Genat (retired) from comment #5)
>       <w:numPr>
>          <w:ilvl w:val="0"/>
>          <w:numId w:val="16"/>
>       </w:numPr>

This is the numbering properties with a reference to numId=16 (available as WWNum16 list style), which can be found in /word/numbering.xml like so

  <w:num w:numId="16">
    <w:abstractNumId w:val="20" />
  </w:num>

This references the abstractNumId=20 (available as ListLabel 20 character style), which also can be found numbering.xml like so

  <w:abstractNum w:abstractNumId="20">
    ...
    <w:lvl w:ilvl="0" w:tplc="0419000F">
      <w:start w:val="1" />
      <w:numFmt w:val="decimal" />
      <w:lvlText w:val="%1." />
      <w:lvlJc w:val="left" />
      <w:pPr>
        <w:ind w:left="720" w:hanging="360" />
      </w:pPr>
      <w:rPr>
        <w:rFonts w:hint="default" />
        <w:b w:val="0" />
      </w:rPr>
    </w:lvl>
    ...
  </w:abstractNum>

And the run properties from here are to overwrite the paragraph run properties below

>       <w:rPr>
>          <w:rFonts w:ascii="Segoe UI Light" w:eastAsia="Times New Roman"
> w:hAnsi="Segoe UI Light" w:cs="Times New Roman"/>
>          <w:b/>
>          <w:bCs/>
>          <w:color w:val="68217A"/>
>          <w:kern w:val="36"/>
>          <w:sz w:val="36"/>
>          <w:szCs w:val="20"/>
>          <w:lang w:val="ru-RU"/>
>       </w:rPr>
>    </w:pPr>

resulting in a combined paragraph/numbering run properties of

<w:rPr>
   <w:rFonts w:hint="default" w:ascii="Segoe UI Light" .../>
   <w:b w:val="0" />
   <w:bCs/>
   <w:color w:val="68217A"/>
   <w:kern w:val="36"/>
   <w:sz w:val="36"/>
   <w:szCs w:val="20"/>
   <w:lang w:val="ru-RU"/>
</w:rPr>

so the numbering should be not-bold and purple, but instead it currently is bold and black.

@Justin, @Mike: What are your thoughts on this? Listlabel 20 is correctly pulling in the latin font size (<w:sz>), but doesnt correctly pull in the font color (<w:color>), no-bold (<w:b>) or the font name or size in asian and ctl.

@Regina: seems like not having direct formatting that can be applied to different list items/characters means we'll be struggling with the likes of this.
Comment 14 QA Administrators 2018-09-28 02:43:24 UTC Comment hidden (obsolete, spam)
Comment 15 Timur 2019-09-06 09:12:38 UTC
DOCX looks better now. Test LO 6.2 and 6.4+. I'll close. 
Chuck's  attachment 117135 [details] also opens OK.
Comment 16 Justin L 2019-09-10 21:52:24 UTC
Confirmed fixed in 6.4 because of commit 2c0d3ce5292b45a8897758508ee61801e4e8340d
Author: Samuel Mehrbrodt
Date:   Fri Aug 30 15:19:49 2019 +0200
    tdf#64222 Consistently apply direct formatting to numbering

*** This bug has been marked as a duplicate of bug 64222 ***