Created attachment 115584 [details] Original.xlsx Windows 7 Version: 5.0.0.0.alpha1+ Build ID: 5b3a30f40a7ce476922649b734f6ede1c2fdef4b TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-05-13_01:52:36 Locale: en-US (en_US) 1) Open original.xlsx in LibreOffice 2) Look at color in cell H2 3) Compare to either the attached Original.pdf or open the same file in Microsoft Word 2013 Observed: The color is slightly off Gimp color codes (HTML Notation from Color Picker): LibreOffice: 3173b2 Microsoft Office 2013: 3174b0
Created attachment 115585 [details] Original.pdf
LO 4.4.3, win7 LO #3173B2 excel2010 #3174B0
So this took me some time to understand: There are a few indirections resulting in my classification as not a bug: So starting at the cell definition we have a xf index of 110, the corresponding xf entry has a fill id of 6, the corresponding fill entry looks lie: <fill> <patternFill patternType="solid"> <fgColor theme="4" tint="-0.499984740745262"/> <bgColor indexed="64"/> </patternFill> </fill> Now reading the spec about indexed="64" we find in the spec inside of 18.8.27 the definition for the indexed colors with 64 having a special system dependent value: indexed="64" System Foreground n/a So this color is actually not specified and we are in unspecified behavior. For us this maps to OOX_COLOR_WINDOWTEXT which is mapped to XML_windowText. Based on this analysis I consider this an correct import by us and the color just implementation and system defined.