none
[MS-OI29500] tblLook/@val additional constants: values correct? RRS feed

  • Question

  • Hi,

    in [MS-OI29500], "2.1.159  Part 1 Section 17.4.56, tblLook (Table Style Conditional Formatting Settings)", four new tblLook/@val constants are listed. The accompanying text says, "This and the following bitmasks are combinations of two bits. These bits allow an intersection of the appropriate row and column."

    Then, it lists e.g.

    0x00A0 - Allow NE Cell conditional formatting

    However, 0xA0 is (0x80 + 0x20), which is - according to ISO/IEC 29500-4 - ("first column" + "first row"). The intersection of this row and column, however, is the north west cell, and not the north east cell as specified for 0x00A0. The situation is similar for the other additional constants.

    Is this an error in [MS-OI29500] (with respect to the wording why bit combinations were chosen for the corner cells it looks like it is) or are the constants indeed correctly specified in [MS-OI29500]?

    Thanks, Christian

    Thursday, May 3, 2012 2:28 PM

Answers

  • Hi Christian,

    Thank you for bringing these inaccuracies to our attention. What you found in [MS-OI29500] v20120412 §2.1.159 is applicable to §2.1.158, too.

    If in Word 2010 in Table Tools / Design / Modify Style / Apply formatting to:
    choose “Top left cell” and on the ribbon mark “Header Row” and “First Column” you can see the effect on the top left cell.

    Checking the generated XML you can see the val is set to “06A0” (0600 is for banded setting) so 00A0 correspond to the top left, i.e. NW cell setting.

    I’ve submitted a request to correct these kinds of errors in the documentation.

    Thanks, Vilmos

    • Proposed as answer by Vilmos Foltenyi Wednesday, May 23, 2012 7:00 PM
    • Marked as answer by kriro Wednesday, May 23, 2012 8:04 PM
    Wednesday, May 23, 2012 6:59 PM

All replies

  • Hi Christian,

    Thank you for your question.  A colleague will contact you soon to investigate this issue.

    Regards,

    Mark Miller | Open Specifications Support Team

    Thursday, May 3, 2012 6:31 PM
  • Hi Christian,

    I am the engineer who will be working with you on this issue. I am currently researching the problem and will provide you with an update soon.

    Regards,
    Vilmos Foltenyi - MSFT

    Friday, May 4, 2012 5:36 AM
  • Hi Christian,

    Thank you for your patience, I'm still researching your case.

    Thanks, Vilmos
    Wednesday, May 16, 2012 4:15 AM
  • Hi Christian,

    Thank you for bringing these inaccuracies to our attention. What you found in [MS-OI29500] v20120412 §2.1.159 is applicable to §2.1.158, too.

    If in Word 2010 in Table Tools / Design / Modify Style / Apply formatting to:
    choose “Top left cell” and on the ribbon mark “Header Row” and “First Column” you can see the effect on the top left cell.

    Checking the generated XML you can see the val is set to “06A0” (0600 is for banded setting) so 00A0 correspond to the top left, i.e. NW cell setting.

    I’ve submitted a request to correct these kinds of errors in the documentation.

    Thanks, Vilmos

    • Proposed as answer by Vilmos Foltenyi Wednesday, May 23, 2012 7:00 PM
    • Marked as answer by kriro Wednesday, May 23, 2012 8:04 PM
    Wednesday, May 23, 2012 6:59 PM
  • Thanks Vilmos for investigating this, that's what I suspected.

    So in short: implementation is correct, current documentation is wrong, and the correct corners are those that are the intersection of the respective column+row bit masks.

    Regards, Christian

    Wednesday, May 23, 2012 8:07 PM
  • So, it's 7 years and a huge number of releases of MS-OI29500 later, but when I download

    https://interoperability.blob.core.windows.net/files/MS-OI29500/%5bMS-OI29500%5d.pdf

    which is reportedly the latest revision (16.0) of this document, those values are still specified wrongly (e.g. §2.1.160).

    Is your assessment above of them being documented wrongly in fact wrong (and the values in the spec are actually correct and Word just does not follow its own implementation description), or have you just not had enough time yet to fix these serious mistakes?

    Thanks for any clarification you may give on this matter,

    Christian

    Tuesday, November 19, 2019 2:58 PM
  • Hi Christian, 

    I will check out the status of our bug on this and see if it was not fixed for some reason. I'll follow up shortly. 

    Best regards,
    Tom Jebo
    Sr Escalation Engineer
    Microsoft Open Specifications

    Tuesday, November 19, 2019 8:07 PM
    Moderator
  • Hi Christian, 

    You're right that this was never corrected. I've filed a new bug to get this reviewed and fixed in [MS-OI29500]. 

    Thank you for bringing it to our attention again after so long. 

    Tom

    Friday, November 22, 2019 3:07 AM
    Moderator