Yoon Kit & Hasan Saidin over at the Open Malaysia blog have a chrystal clear view of one of the ways Microsoft Office Open XML contradicts existing global technology standards. It ignores the WC3 SVG standard.
The problem is explained in some further detail here -- follow the link, "Ecma 376 contradicts numerous international standards".
Yoon Kit rhetorically asks why, and the answer has to do with Microsoft's commitment to its non-standard methods in many products throughout the product catalog and its corporate business model based as it is upon technical dependencies which are (were once) invisible to the customer.







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 Kit & Saidin arrived at the Microsoft color choices and whether this was in anything normative. A link would have been nice. I assume you mean this: http://www.openmalaysiablog.com/2007/01/msooxml_contrad.html
Furthermore, 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 precision for these colors and color-name codes is a big deal.
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 although the coded-names (which do not in any way use SVG namespaces) abbreviate "dark" to "dk" and "light" to "lt". The codes that Kit & Saidin choose to illustrate are perfectly convertible between SVG and DrawingML, without any loss and with no mystery.
Posted by: orcmid | January 28, 2007 at 01:25 PM
Thanks for your informative comment, Dennis.
(The link to Open Malaysia blog was through clicking the graphic. Regular PlexNex readers can rely on it. Sorry it wasn't more obvious.)
Posted by: Sam Hiser | January 28, 2007 at 02:34 PM
Oops, the link is in the image. I missed it.
Posted by: orcmid | January 28, 2007 at 02:36 PM
Dennis (orcmid),
You have my full reply to your query here:
Please correct any mistakes / misunderstandings I may have made.
yk.
Posted by: yoonkit | January 29, 2007 at 04:27 AM