Bug 114158 - FILEOPEN DOCX: Color 'Automatic' of characters in a textbox not recognized
Summary: FILEOPEN DOCX: Color 'Automatic' of characters in a textbox not recognized
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks: DOCX-Character
  Show dependency treegraph
 
Reported: 2017-11-30 06:24 UTC by Mike
Modified: 2018-02-12 09:09 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Minimum test case (10.57 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-11-30 06:25 UTC, Mike
Details
Minimum test case, where color is specified as black (10.64 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-11-30 06:26 UTC, Mike
Details
Screenshots and description (240.54 KB, application/pdf)
2017-11-30 06:26 UTC, Mike
Details
Minimum test case (got the wrong one, marked it as obsolete. Sorry.) (10.42 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-11-30 06:28 UTC, Mike
Details
modified test case (10.43 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-11-30 06:29 UTC, Mike
Details
modified test case (10.42 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-11-30 06:29 UTC, Mike
Details
description with screen shots (got the wrong one first. I'm sorry.) (1.39 MB, application/pdf)
2017-11-30 06:31 UTC, Mike
Details
test case - I added some text in color 'automatic' outside the text box. LO displays it. (10.52 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-11-30 06:32 UTC, Mike
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike 2017-11-30 06:24:57 UTC
Description:
The test case has a box filled with text in color „Automatic“. In this context that means black color (value #000000). But LO interprets the color as plain white (value #FFFFFF). (only LO 4.4 and newer.) 



Steps to Reproduce:
1. Mark the invisible text in the box by clicking inside the box and moving the cursor.
2. Open the context menu by clicking right.
3. Choose „Character“.
4. Choose „Font Effects“. → Font color is set „White“.
5. Click on „Font color“ and choose „Automatic“.
6. Click „OK“. → The font is now displayed in black color- So black is correct, if the color is set to „Automatic“.

Actual Results:  
The color of the characters in the text box is set to white (value #FFFFFF.

Expected Results:
The color of the characters in the text box is set to "automatic".


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
The original file (not included, big file) was created another person with MS Word, but I made  a minimum test case from it with „ThinkFree Office Word“. There I set the color of the font to white respective black and saved them. LO shows the correct color in these files. They are attached:

„2 lines in document.xml added, if color is set to white (#FFFFFF).docx“ and 
„4 lines in document.xml added, if color is set to black (#000000).docx“

1st doc: in word\document.xml  <w:color w:val="FFFFFF"/> are added in lines 97 and 148
2nd doc:  in word\document.xml <w:color w:val="000000"/> are added in lines 86, 98, 138 and 150

How older versions of LO handle this issue:

1. Open test case with a  LO version 3.6 to 4.2 (LO 4.4 and more recent behave like the lastest build.)
2. Click in the white space above the black line on the top of the page
3. Move the cursor to the little green square, that is centered bottom.
You will now see a vertical white line with arrow on both sides.
4. Move this arrow down with your mouse.
5. Let loose of the cursor.
Now you will see the text of the text box in black color. 
6. To see the character properties start spelling correction by „Tools“ -> „Spelling and Grammar“. (Maybe there is a quicker way… )
7. Close windows „Spelling and Grammar“.
8. Now mark the text and look up the font color: It‘s „Automatic“.

LO 4.2 gets height and position of textbox wrong, but I you increase the height by draging the lower little green square of the box down. Then you will see the text in correct color.

LO 3.6:
Textbox has the height of a single horizontal line.
Otherwise same as LO 4.2.

LO 3.5: The font has the correct color and the content of the box is shown (unlike 3.3!) But the shape of the box is messed up.

LO 3.3: Color of font is correct, but height of text box is wrong and no text in box is displayed.

I attached several files and a pdf with screenshots.

Version: 6.0.0.0.beta1 (x64)
Build ID: 97471ab4eb4db4c487195658631696bb3238656c
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: de-DE (de_DE); Calc: CL

I searched for dupes, but found nothing.



User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Comment 1 Mike 2017-11-30 06:25:29 UTC Comment hidden (obsolete)
Comment 2 Mike 2017-11-30 06:26:17 UTC Comment hidden (obsolete)
Comment 3 Mike 2017-11-30 06:26:42 UTC Comment hidden (obsolete)
Comment 4 Mike 2017-11-30 06:28:34 UTC
Created attachment 138097 [details]
Minimum test case (got the wrong one, marked it as obsolete. Sorry.)
Comment 5 Mike 2017-11-30 06:29:22 UTC
Created attachment 138098 [details]
modified test case
Comment 6 Mike 2017-11-30 06:29:43 UTC
Created attachment 138099 [details]
modified test case
Comment 7 Mike 2017-11-30 06:31:02 UTC
Created attachment 138100 [details]
description with screen shots (got the wrong one first. I'm sorry.)
Comment 8 Mike 2017-11-30 06:32:00 UTC
Created attachment 138101 [details]
test case - I added some text in color 'automatic' outside the text box. LO displays it.
Comment 9 Buovjaga 2017-12-03 14:23:15 UTC
Yep, color is black in older versions

Version: 6.1.0.0.alpha0+ (x64)
Build ID: cc1db6f2b0ebe05ae807628778835b62df00eca2
CPU threads: 4; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-12-03_00:59:10
Locale: fi-FI (fi_FI); Calc: group threaded

Arch Linux 64-bit
Version 3.6.7.2 (Build ID: e183d5b)
Comment 10 raal 2017-12-30 21:16:31 UTC
This seems to have begun at the below commit.
Adding Cc: to Miklos Vajna ; Could you possibly take a look at this one?
Thanks
 5f8e6a6936fea433ca66a1e2cceee66e6616d88f is the first bad commit
commit 5f8e6a6936fea433ca66a1e2cceee66e6616d88f
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Sun Mar 15 03:18:52 2015 +0800

    source-hash-5bab5aae165158621dcf740be9bee9fca808aa9d
    
    commit 5bab5aae165158621dcf740be9bee9fca808aa9d
    Author:     Miklos Vajna <vmiklos@collabora.co.uk>
    AuthorDate: Wed Oct 1 12:53:27 2014 +0200
    Commit:     Miklos Vajna <vmiklos@collabora.co.uk>
    CommitDate: Wed Oct 1 13:02:47 2014 +0200
    
        DOCX drawingML import: handle char color from theme for shape text
    
        When we import table styles, we apply that as direct formatting, in case
        there is no real direct formatting, see lcl_ApplyCellProperties() in the
        sw UNO implementation.
    
        We can do the same here: in case there is no other formatting, then
        apply the char color from the WPS theme, that will give us the expected
        result.
    
        Change-Id: Ic8e6afc09167f7924a11ab0b445351075f16738e
Comment 11 Miklos Vajna 2018-02-09 20:19:10 UTC
I'm confused. Could you please point out exactly what attachment has a rendering problem? I tried http://bugs.documentfoundation.org/attachment.cgi?id=138097 and http://bugs.documentfoundation.org/attachment.cgi?id=138101, and in both cases the rendering result (white-on-white) matches the Word one as far as I see.
Comment 12 Buovjaga 2018-02-12 09:09:24 UTC
(In reply to Miklos Vajna from comment #11)
> I'm confused. Could you please point out exactly what attachment has a
> rendering problem? I tried
> http://bugs.documentfoundation.org/attachment.cgi?id=138097 and
> http://bugs.documentfoundation.org/attachment.cgi?id=138101, and in both
> cases the rendering result (white-on-white) matches the Word one as far as I
> see.

Miklos is right. We have all been mistaken because we did not test with Word. Word 2013 shows the text as white on white. Closing.