Bug 80961 - FILEOPEN: DOCX colored bullet points not retaining color
Summary: FILEOPEN: DOCX colored bullet points not retaining color
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version: 4.2.6.1 rc
Hardware: Other All
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: bibisected interoperability ooxml
Keywords: bisected, regression
Depends on:
Blocks:
 
Reported: 2014-07-05 22:42 UTC by Jay Philips
Modified: 2014-10-16 14:59 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
4.2 VS 4.3 (204.10 KB, image/png)
2014-07-05 22:42 UTC, Jay Philips
Details
word 2013 pdf version of the docx file (326.60 KB, application/pdf)
2014-07-08 07:57 UTC, Jay Philips
Details

Description Jay Philips 2014-07-05 22:42:16 UTC
Created attachment 102311 [details]
4.2 VS 4.3

When i was retesting < http://download.microsoft.com/documents/rus/microsoft4you/How_to_license_the_operating_system_Windows_8_new.docx > from bug 77797 in LibO 4.3.1, i noticed that colored bullet points arent retaining their color. This is a regression as 4.2.
Comment 1 tommy27 2014-07-06 08:27:02 UTC
good catch Jay.
I confirm regression in 4.3.0.2 where the bullets are dark gresy instead of purple like in 4.2.x

tested under Win7x64
Comment 2 Jay Philips 2014-07-06 18:13:39 UTC
thanks tommy. wish to see you in the IRC sometime :)

seems that i'll have to go through my extensive interoperability tests again once 4.3 is officially released, to see how it compares with my 4.2.4 results.
Comment 3 Owen Genat 2014-07-08 07:35:38 UTC
(In reply to comment #0)
> i noticed that colored bullet points arent retaining their color. 
> This is a regression as 4.2.

I am not convinced this is a regression or even a bug. As I commented here:

https://bugs.freedesktop.org/show_bug.cgi?id=77797#c5

... this appears to be a case of the XML previously (under v4.2.x) not being correctly interpreted, where now (v4.3.x) it is. The XML for the first item of the unordered list on the first page of the document is:

<w:p w:rsidR="0054188B" w:rsidRPr="003A3302" w:rsidRDefault="0054188B" w:rsidP="003A3302">
   <w:pPr>
      <w:pStyle w:val="ListParagraph"/>
      <w:numPr>
         <w:ilvl w:val="0"/>
         <w:numId w:val="33"/>
      </w:numPr>
      <w:spacing w:after="120" w:line="360" w:lineRule="auto"/>
      <w:rPr>
         <w:rFonts w:eastAsia="Times New Roman" w:cs="Times New Roman"/>
         <w:color w:val="505050"/>
         <w:szCs w:val="20"/>
         <w:lang w:val="ru-RU"/>
      </w:rPr>
   </w:pPr>
   <w:r w:rsidRPr="003A3302">
      <w:rPr>
         <w:rFonts w:eastAsia="Times New Roman" w:cs="Times New Roman"/>
         <w:color w:val="505050"/>
         <w:szCs w:val="20"/>
         <w:lang w:val="ru-RU"/>
      </w:rPr>
      <w:t xml:space="preserve">Как правильно выбрать вид лицензии </w:t>
   </w:r>
   <w:r w:rsidRPr="003A3302">
      <w:rPr>
         <w:rFonts w:eastAsia="Times New Roman" w:cs="Times New Roman"/>
         <w:color w:val="505050"/>
         <w:szCs w:val="20"/>
      </w:rPr>
      <w:t>Windows</w:t>
   </w:r>
   <w:r w:rsidRPr="003A3302">
      <w:rPr>
         <w:rFonts w:eastAsia="Times New Roman" w:cs="Times New Roman"/>
         <w:color w:val="505050"/>
         <w:szCs w:val="20"/>
         <w:lang w:val="ru-RU"/>
      </w:rPr>
      <w:t xml:space="preserve"> 8 для новых и уже используемых ПК? </w:t>
   </w:r>
</w:p>

All the w:color elements specify grey (505050) rather than the purple (68217A) indicated. Even in the associated styles.xml file the only definitions specifying a color of 68217A are: Heading1 (paragraph), Heading2 (paragraph), Heading1Char (character), Heading2Char (character), Header (paragraph), and Sidebarheading (paragraph).
Comment 4 Jay Philips 2014-07-08 07:57:18 UTC
Created attachment 102417 [details]
word 2013 pdf version of the docx file

Well it seems confusing that 4.2.5 shows it in purple and 4.3.0 shows it in grey, so your saying 4.2.5 is showing it incorrectly then. And that is so, why does word 2013 show it in purple, as show in the attached pdf.
Comment 5 Joel Madero 2014-07-08 15:40:24 UTC
It's interesting because I don't see the bullet arrows at all on my system and only see hollow boxes.

@Jay - special font of some kind needed? Are you opening this in Windows or Linux or both?
Comment 6 Jay Philips 2014-07-08 16:42:05 UTC
Here is the list of fonts used by the docx - Symbol, Times, Courier, Wingdings, Wingdings 3, Segoe UI, SegoeCondensed, Arial, Segoe UI Light, Tahoma, Verdana. I have them installed on both systems, thats the only way you can do real extensive testing like i used to do. :)

Looking forward to the 4.3 release so i can do tests just comparing 4.2 vs 4.3 and see how far interoperability has improved/deteriorated since my last round. Better get ready for alot of bibisect requests joel. :)
Comment 7 Michael Stahl 2014-07-11 21:49:11 UTC
works in 4.2.5.2, broken in 4.2.6.1

regression from 

commit 2d89b1a029514935b60fbd3f7f7c5341a329bfc8
Author:     Luboš Luňák <l.lunak@collabora.com>
AuthorDate: Thu May 29 14:31:20 2014 +0200

    handle direct formatting for numbering in .docx (bnc#875717)
    

the relevant part of word/numbering.xml is apparently:

  <w:abstractNum w:abstractNumId="27">
    <w:nsid w:val="5FDA0759"/>
    <w:multiLevelType w:val="hybridMultilevel"/>
    <w:tmpl w:val="386A8832"/>
    <w:lvl w:ilvl="0" w:tplc="D5A2443C">
      <w:start w:val="1"/>
      <w:numFmt w:val="bullet"/>
      <w:lvlText w:val=""/>
      <w:lvlJc w:val="left"/>
      <w:pPr>
        <w:ind w:left="720" w:hanging="360"/>
      </w:pPr>
      <w:rPr>
        <w:rFonts w:ascii="Wingdings 3" w:hAnsi="Wingdings 3" w:hint="default"/>
        <w:color w:val="68217A"/>
      </w:rPr>
    </w:lvl>


this is imported as char style "ListLabel 1",
with the right colour in it as displayed by the style dialog,
but in the document grey is displayed instead.
Comment 8 Owen Genat 2014-07-12 13:32:26 UTC
(In reply to comment #7)
> works in 4.2.5.2, broken in 4.2.6.1
...
> the relevant part of word/numbering.xml

Apologies to both Jay and others. My mistake. Thanks for correcting me Michael.
Comment 9 Björn Michaelsen 2014-10-16 14:59:04 UTC
(This is an automated message.)

It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.)

Thus setting keyword "bisected".


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.