Promoting ODF (OpenDocument Format),MSOOXML contradicts W3C SVG Colour definitions
With the huge adoption of W3C standards like HTML, XML and SVG, we would assume that MSOOXML would conform to the well used standards. However MSOOXML colour values contradict W3C SVG's specifications.
In section 2.18.46 (page 2521) the specification lists Red-Green-Blue (RGB) values for common colour names which correlate with the standard W3C SVG Color Keyword Names. However, the hexadecimal RGB values differ with the same colour names:
“Light Gray”, “Dark Gray” and “Dark Green” show the
most visible differences and this will cause significant confusion
and frustration for documents which need to represent colours with
high fidelity.
In contrast, section 5.1.12.48 (p. 4531) "ST_PresetColorVal" (Preset Color Value) matches W3C SVG colors well, in that the RGB values are exactly the same. Unfortunately, it renames "darkGray" to "dkGray" and "lightGray" to "ltGray" to avoid self-contradiction at the cost of preventing harmonization with the W3C SVG standard.
We need to find out why a mature specification like MSOOXML would need to redefine a well known and well used colour definition (SVG) and also redefine it twice (2.18.46 and 5.1.12.48) within its own specification?
yk.
The Windows color choices that you exhibit are selected from the *standard* color map that is defined for HTML/XHTML.
The idea is to make sure there is accurate rendering on a wide range of displays. The standard color map does not use color levels 64, 8B, A9, or D3 (although 00 is a universal winner for "darkest").
It would appear that SVG conflicts with another older and far more widely-used W3C standard. Fancy that.
Of course, all of the color *codes* can be used in Microsoft Office and OOX, the problem here seems to be about color *coded-names*.
With regard to the coded-names for the 10 office standard *text* colors (beside white and black and the greys), Microsoft names them Dark Red, Red, Orange, Yellow, Light Green, Green, Light Blue, Blue, Dark Blue, and Purple in the en-us UI of Office Word 2007 (B2TR, I'll install the RTM version later today). They seem to be careful to avoid the names that are not that well-known (e.g., teal, maroon, and so on).
I placed text phrases of the same color as the phrase into a .DOCX file and see that names are not used in the XML. Color codes are used. These are the color values used for my choices: C00000 (dark red), FF0000, FFC000, FFFF00, 92D050, 00B050, 00B0F0, 0070C0, 002060, and 7030A0 (purple). There are a number of color levels outside of the standard subset here: 20, 50, 70, 92, B0, C0, D0, and F0.
This leads me to wonder how you arrived at the Microsoft color-code choices.
Section 2.18.46 (of the Markup Reference volume) is about text *highlighting* color -- for highlighting over text, not a normal color or color settings used elsewhere. There is only one listed reference to this standard type from elsewhere in the specification and it is for highlighting text in WordML. There are a fixed number of values (you can't specify your own code), so color coded-names must be used in OOX for the hightlighting attribute, but we know what the corresponding codes are. The human-understandable names (not color-attribute values) all say "Highlight Color" quite prominently. This is apparently not a place where anyone things having rigorous precision for these color name-codes is a big deal. They don't apply to SVG or to DrawingML at all.
With regard to Drawing ML (section 5.1), section 5.1.12.48 specifies Preset Color Values that are only used within that format. In this portion of the specification, the code values are identical to the SVG ones you offer, although the coded-names (which do not in any way use SVG namespaces) abbreviate "dark" to "dk" and "light" to "lt". These are strictly-defined and perfectly convertible between SVG and DrawingML, without any loss and with no mystery. Some conflict.
Posted by: orcmid | Monday, 29 January 2007 at 02:32 AM
I haven't checked carefully, bit I wonder if it would be a good idea to examine ODF to make sure it doesn't have any similar "contradiction" before pouncing on OOXML.
Posted by: orcmid | Monday, 29 January 2007 at 02:43 AM
Dennis (orcmid),
My reply to your query is in my next blog post here:
/2007/01/msooxmls_disreg.html
yk.
Posted by: yoonkit | Monday, 29 January 2007 at 05:29 PM