Bug 77962 - FILEOPEN: WPS DOC - incorrect font colours imported (16 palette colours = use comment 11's doc)
Summary: FILEOPEN: WPS DOC - incorrect font colours imported (16 palette colours = use...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:7.1.0 target:7.0.1 target:6.4.6
Keywords: filter:doc
: 77860 (view as bug list)
Depends on:
Blocks: DOC-Character
  Show dependency treegraph
 
Reported: 2014-04-26 11:23 UTC by Yousuf Philips (jay) (retired)
Modified: 2021-06-22 06:00 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
the font color was supposed to be cyan and not green (3.36 KB, image/png)
2014-04-26 11:23 UTC, Yousuf Philips (jay) (retired)
Details
doc file produced by kingsoft writer (242.50 KB, application/msword)
2014-04-26 11:26 UTC, Yousuf Philips (jay) (retired)
Details
comparative screenshot LibO (top) and Word Viewer (bottom) (200.65 KB, image/jpeg)
2014-06-15 15:02 UTC, tommy27
Details
kingsoft/wps doc with colors (12.00 KB, application/wps-office.doc)
2017-09-27 00:24 UTC, Yousuf Philips (jay) (retired)
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-26 11:23:50 UTC
Created attachment 98015 [details]
the font color was supposed to be cyan and not green

I download the .docx file found at < http://download.microsoft.com/documents/customerevidence/Files/710000003670/Xiamen_Tungsten_Group_unifies_enterprise.docx > and opened it with kingsoft writer and then saved it as an DOC. When i opened the DOC in LibO, on page 1, the colored second line has turned into green rather than being blue. Tested in 3.6 - 4.3.
Comment 1 Yousuf Philips (jay) (retired) 2014-04-26 11:26:23 UTC
Created attachment 98016 [details]
doc file produced by kingsoft writer
Comment 2 Urmas 2014-04-26 11:35:39 UTC
Confirmed in master.
Comment 3 Alexandr 2014-04-27 09:12:50 UTC
Reproducible in LibreOffice 3.5.4 on Debian Wheezy.

According to https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Version 
"We currently use the Version field to store the earliest LibreOffice version on which we can reproduce a bug". So I change the version field.
Comment 4 Yousuf Philips (jay) (retired) 2014-04-27 11:04:48 UTC
(In reply to comment #3)
> Reproducible in LibreOffice 3.5.4 on Debian Wheezy.
> 
> According to https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Version 
> "We currently use the Version field to store the earliest LibreOffice
> version on which we can reproduce a bug". So I change the version field.

Thanks for testing it on 3.5 and changing it.
Comment 5 tommy27 2014-06-15 15:02:48 UTC
Created attachment 101100 [details]
comparative screenshot LibO (top) and Word Viewer (bottom)

I confirm issue in OOo 3.3.0 and all LibO release up to 4.2.4.2 under Win7x64
so bug is inherited from OOo

I attach a bigger comparative screenshot to better show the difference in color
Comment 6 QA Administrators 2015-07-18 17:43:47 UTC Comment hidden (obsolete)
Comment 7 tommy27 2015-07-19 05:48:40 UTC
bug persists in LibO 4.4.5.1 and 5.1.0.0.alpha1+ (x64)
Build ID: 5a61d7f049a81d6e747d9d097f364ae45f58697b
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-07-16_01:06:26
Locale: en-US (it_IT)
Comment 8 QA Administrators 2016-09-20 10:17:58 UTC Comment hidden (obsolete)
Comment 9 Justin L 2017-09-26 18:48:08 UTC
I round-tripped the file from comment 1 in MSO2003.  LibreOffice properly shows a cyan color on those round-tripped files. So, does this mean that Kingsoft used a non-palette color, and MSO automatically converts it to the nearest palette color?
Comment 10 Yousuf Philips (jay) (retired) 2017-09-27 00:20:28 UTC
(In reply to Justin L from comment #9)
> I round-tripped the file from comment 1 in MSO2003.  LibreOffice properly
> shows a cyan color on those round-tripped files.

Interesting.

> So, does this mean that Kingsoft used a non-palette color, and MSO
> automatically converts it to the nearest palette color?

You can use non-palette colors in Word 2003 and the original docx file mentioned in comment 0 used the same cyan color. Maybe kingsoft is saving it in a way that LO isnt able to understand but is part of the spec. All i know is that Word 2003/2007/2010 and WPS Writer all show it as RGB(0,114,198) and LO is opening it as RGB(0,128,128).
Comment 11 Yousuf Philips (jay) (retired) 2017-09-27 00:24:55 UTC
Created attachment 136557 [details]
kingsoft/wps doc with colors

Here is a sample .doc from WPS with a variety of colors and LO only gets these ones right.

Red rgb(255,0,0)
Yellow rgb(255,255,0)
Comment 12 Alexandr 2017-10-21 18:54:36 UTC
Reproducible with  LibreOffice 5.2.7 and 6.0.0.0.alpha1 on Debian Jessie.
Comment 13 QA Administrators 2018-10-22 02:47:32 UTC Comment hidden (obsolete, spam)
Comment 14 Justin L 2020-07-16 14:39:34 UTC
There is a "new" sprmCCv used by Read_TextForeColor which can be any RGB color - and that is what is processed after Word 2003 roundtrips the file.

In this Kingsoft document, LO can only use the older sprmCIco, read by Read_TextColor, which references a 16 bit table defined by 2.9.119 Ico

There are a lot of errors when reading this document:
    sprm longer[6] than remaining[4] bytes, doc or parser is wrong

mso-dumper does indicate that CCv sprms exists in the document, but they are never seen/processed in LO.

<prl type="Prl" offset="4541" index="0">
<sprm value="0x2a42" ispmd="0x42" fSpec="0x1" sgc="character" spra="1" name="sprmCIco" operandSize="1" operand="0x10"/>
</prl>
<prl type="Prl" offset="4544" index="1">
<sprm value="0x4a60" ispmd="0x60" fSpec="0x1" sgc="character" spra="2" name="sprmCIcoBi" operandSize="2" operand="0x10"/>
</prl>
<prl type="Prl" offset="4548" index="2">
<sprm value="0x6870" ispmd="0x70" fSpec="0x0" sgc="character" spra="3" name="sprmCCv" operandSize="4" operand="0xe7c6b4"/>

=====================================================================
proposed fix at http://gerrit.libreoffice.org/c/core/+/98911
Comment 15 Commit Notification 2020-07-16 16:24:15 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/56b04e40ab72b6333ce278ba2980650f5272025f

tdf#77962 ww8import: 0x4xxx sprms are always 2 byte

It will be available in 7.1.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 16 Commit Notification 2020-07-16 20:03:10 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/52f004e27fbdef114a6fa1b467a7919ab1762dab

tdf#77962 ww8import: 0x4xxx sprms are always 2 byte

It will be available in 7.0.1.

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 17 Commit Notification 2020-07-17 07:10:11 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/8f37d303905c85dfa5027976d504b9b4904accce

tdf#77962 ww8import: 0x4xxx sprms are always 2 byte

It will be available in 6.4.6.

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 18 Justin L 2021-06-22 06:00:53 UTC
*** Bug 77860 has been marked as a duplicate of this bug. ***