The hueDir attribute of a <dgm:fillClrLst> element does not work

Regina Henschel 406 Reputation points
2026-05-29T14:32:04.79+00:00

I have an element 

<dgm:fillClrLst meth="span" hueDir="ccw">
    <a:schemeClr val="accent2"/>
    <a:schemeClr val="accent3"/>
</dgm:fillClrLst>

According to chapter 21.4.7.38 ST_HueDir (hue Direction) this should generate counter-clockweise hue interpolation. Take the example accent2=RGB(233,113,50), accent3=RGB(25,107,36). So accent2 is a red and accent3 is a green. With a clockwise direction the hue interpolation goes through Yellow. With a counter-clockwise direction it should go through Blue. But PowerPoint always renders it with Yellow as intermediate color. Might it be, that PowerPoint does not support the hueDir attribute at all? I do not see such restriction mentioned in [MS-OI29500].

Or do I miss something to make it interpolate counter-clockwise? I have already changed the uniqueId to not have a microsoft.com part in it, but that does not help. Sadly I cannot attach the pptx file. However, I can sent it to you if you provide me an email address.

Microsoft 365 and Office | Open Specifications
Microsoft 365 and Office | Open Specifications

Technical documents for protocols, computer languages, standards support, and data portability. The goal with Open Specifications is to help developers open new opportunities to interoperate with Windows, SQL, Office, and SharePoint.

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Mike Bowen 2,226 Reputation points Microsoft Employee Moderator
    2026-06-19T21:45:22.6433333+00:00

    Hi @Regina Henschel ,

    After researching this issue, I can confirm that you are correct, PowerPoint ignores the hueDir attribute. There will be an update to MS-OI29500 in an upcoming release with this information.

    Thanks for all your efforts to help maintain our documentation, we very much appreciate it. Let me know if you have any other questions regarding this issue.

    Best regards, Michael Bowen Microsoft Open Specifications Support

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments
  2. Hin-V 16,830 Reputation points Microsoft External Staff Moderator
    2026-05-29T17:35:11.2733333+00:00

    Hi @Regina Henschel

    Thank you for sharing your concern. 

    First, I’d like to clarify that this is a user‑to‑user support forum. Moderators participating here do not have access to backend systems, nor can we directly intervene in Microsoft product functionality. Our role is limited to providing technical guidance and sharing best‑practice recommendations based on reported issues, requests, and scenarios. 

    Currently, I have not found any related information or official documentation that directly addresses this specific behavior. Based on my research, the hueDir attribute is intended to control the direction around the color wheel, and its default value is cw. Microsoft’s implementation note for fillClrLst explicitly states that Office ignores hueDir when meth="repeat". However, I could not find a corresponding Microsoft note stating that hueDir is also ignored when meth="span"

     2.1.1678 Part 4 Section 5.9.4.8, fillCIrLst (Fill Color List) +. Summarize this article for me a. The standard states that the fillClrLst element defines a list of colors which are used as fill colors in the color transform, and that those fill colors define the colors of the nodes in a diagram. Office uses this element to specify a color sequence to be applied to the fill of the associated presentation elements of a diagram. b. The standard places no restrictions on the relationship between the meth attribute and the hueDir attribute. Office ignores the hueDir attribute if the value of the meth attribute is repeat.

    Reference: 2.1.1678 Part 4 Section 5.9.4.8, fillClrLst (Fill Color List)

    Since this behavior is not clearly documented in the references I found, I cannot say with certainty that hueDir attribute is unsupported in this case. To help you reach your goal more effectively, I recommend engaging with [GitHub Community Forum] for a deeper technical dive or to connect with individuals who have relevant experience and expertise. Some approaches may behave differently or be restricted depending on your specific environment and configuration. These forums include many experienced developers and Microsoft specialists who can assist with troubleshooting and guidance.      

    If you have any additional concerns, feel free to comment below. I would be more than happy to assist. 

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread. 

    Was this answer helpful?

  3. AI answer

    2026-05-29T14:32:19.43+00:00

    PowerPoint does not implement every Open XML feature defined in ISO/IEC 29500, and the available information indicates that hueDir is one of the attributes that is effectively ignored by the PowerPoint rendering engine.

    The Open XML schema defines the hue direction for diagram color interpolation via:

    • ColorsType.HueDirection → hueDir attribute
    • HueDirectionValues enum with the values:
      • Clockwise → serialized as "cw"
      • Counterclockwise → serialized as "ccw"

    This is exactly what is being used in the sample:

    <dgm:fillClrLst meth="span" hueDir="ccw">
    <a:schemeClr val="accent2"/>
    <a:schemeClr val="accent3"/>
</dgm:fillClrLst>

    The schema and API clearly support both directions, but there is no additional requirement or setting in the provided documentation that must be enabled to make hueDir="ccw" take effect. Given that:

    • The attribute is correctly formed according to the schema ("ccw" for counterclockwise).
    • The enum and property definitions do not specify any conditional behavior or limitations.
    • PowerPoint still interpolates via yellow (clockwise path) regardless of hueDir.

    The behavior described is consistent with PowerPoint not honoring the hueDir attribute in practice, even though it is valid in the Open XML format. There is nothing else in the provided documentation that would change this behavior or that needs to be added to the markup to force counterclockwise interpolation.

    In other words, the markup is correct per the standard and APIs, but PowerPoint’s implementation appears to ignore hueDir, so counterclockwise interpolation cannot be reliably achieved via this attribute in current builds.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.