none
ST_PathFillMode color shade calculation method... RRS feed

  • Question

  • Hi,

    I am using ECMA-376 spec which defines PathFillMode is defined as follows

    darken (Darken Path Fill) This specifies that the corresponding path should have a darker shaded color applied to it’s fill.
    darkenLess (Darken Path Fill Less) This specifies that the corresponding path should havea slightly darker shaded color applied to it’s fill.
    lighten (Lighten Path Fill) This specifies that the corresponding path should have a lightly shaded color applied to it’s fill.
    lightenLess (Lighten Path Fill Less) This specifies that the corresponding path should have a slightly lighter shaded color applied to it’s fill.
    none (No Path Fill) This specifies that the corresponding path should have no fill.
    norm (Normal Path Fill) This specifies that the corresponding path should have a normally shaded color applied to it’s fill.

    This is too vague to understand.

    Does anyone know the exact way to calculate the values of these shades given a color and fillMode.

    Thanks in advance

    --

     

     

    Thursday, January 27, 2011 10:03 AM

Answers

  • Terlo,

    The alpha component is not affected by the blend.

    When the transforms are cast back to a byte after calculation, this is how the values are affected. There is nothing special done in terms of rounding. This is how the values worked out.

     

    Tuesday, April 12, 2011 1:24 PM

All replies

  • Hi Commando_dhruv:

    I have alerted protocol documentation team regarding your inquiry. A member of the team will be in touch soon through this thread.


    Regards, Obaid Farooqi
    Thursday, January 27, 2011 5:23 PM
    Owner
  • commando-dhruv,

    I am the engineer who has taken ownership of your question. I am currently investigating this matter and will update you as things progress.

    Dominic Salemno
    Escalation Engineer
    Open Specifications

    Thursday, January 27, 2011 9:06 PM
  • commando-dhruv,

    I am still investigating this issue and will update you on this matter shortly.

    Dominic Salemno
    Escalation Engineer
    Open Specifications

    Thursday, February 10, 2011 3:09 AM
  • commando-dhruv,

    darken/darkenLess and lighten/lightLess are calculated based off a simple blend of black or white respectively:

    darken – 40% blend of black
    darkenLess – 20% blend of black
    lighten – 40% blend of white
    lightenLess – 20% blend of white

    I hope this assists you.

    Dominic Salemno
    Escalation Engineer
    Open Specifications

    • Proposed as answer by King Salemno Thursday, February 10, 2011 3:22 AM
    Thursday, February 10, 2011 3:22 AM
  • Would these blends affect the alpha component or is that left alone?

    Also, does PowerPoint do some kind of special rounding on resulting values. I noticed that the blend PowerPoint does is not 100% accurate with the numbers you listed above. For example:

      R G B
    Normal 79 129 189
    lighten
    PowerPoint 149 179 215
    Calculation 149.4 179.4 215.4
    lightenLess
    PowerPoint 114 154 202
    Calculation 114.2 154.2 202.2
    darken
    PowerPoint 47 77 113
    Calculation 47.4 77.4 113.4
    darkenLess
    PowerPoint 64 104 152
    Calculation 63.2 103.2 151.2

    This was tested again the 'bevel' shape. You'll notice in darkenLess, the Red, Green and Blue values (highlighted in red) are rounded up in PowerPoint, inconsistent with the rest of the calculations. I've tried in this in sRGB 0.0-1.0 space as well and the inconsistent rounding results are the same.

     

    Thursday, March 3, 2011 11:17 PM
  • Terlo,

    I am still investigating this.

    Tuesday, March 22, 2011 1:42 PM
  • Terlo,

    The alpha component is not affected by the blend.

    When the transforms are cast back to a byte after calculation, this is how the values are affected. There is nothing special done in terms of rounding. This is how the values worked out.

     

    Tuesday, April 12, 2011 1:24 PM
  • Great, thanks King for the details. Appreciate it!
    Tuesday, April 12, 2011 5:04 PM