iOfficeAI/OfficeCLI · error · ArgumentException

Invalid '{propertyName}' value '{value}': degrees must be in

Error message

Invalid '{propertyName}' value '{value}': degrees must be in [-3600, 3600].

What it means

Thrown by ParseHelpers.SafeParseRotationDegrees when a rotation value (in degrees) falls outside [-3600, 3600]. The clamp exists because OOXML stores angles as ST_Angle (60000ths of a degree); the deg*60000 multiply risks Int32 overflow near +/-35792°, and anything beyond ~ten revolutions is geometrically identical to its mod-360 reduction. Applied uniformly across PPT shape/group/connector add+set rotation sites.

Source

Thrown at src/officecli/Core/ParseHelpers.cs:506

            || double.IsNaN(result) || double.IsInfinity(result))
            throw new ArgumentException($"Invalid '{propertyName}' value '{value}'. Expected a finite number.");
        return result;
    }

    /// <summary>
    /// Parse a rotation value in degrees. Rejects non-finite, NaN, and values
    /// outside [-3600, 3600] degrees (ten full revolutions either direction).
    /// OOXML stores rotation as ST_Angle (60000ths of a degree) which fits in
    /// an Int32 up to ~±35790°, but values above ~±3600° are functionally
    /// indistinguishable from their modulo-360 reduction while opening the
    /// door to silent overflow on the (deg * 60000) multiply. The clamp is
    /// applied uniformly across pptx shape/group/connector add+set sites.
    /// </summary>
    public static double SafeParseRotationDegrees(string value, string propertyName)
    {
        var deg = SafeParseDouble(value, propertyName);
        if (deg < -3600 || deg > 3600)
            throw new ArgumentException($"Invalid '{propertyName}' value '{value}': degrees must be in [-3600, 3600].");
        return deg;
    }

    /// <summary>
    /// Convert a linear-gradient angle in whole degrees to OOXML
    /// ST_PositiveFixedAngle units (60000ths of a degree). The raw
    /// `degrees * 60000` multiply overflows Int32 for |degrees| ≳ 35792
    /// (e.g. 99999° wraps to a garbage 1.7e9 angle that real Excel refuses
    /// with 0x800A03EC). Reducing modulo 360 first keeps the value in the
    /// spec range [0, 21600000) — geometrically identical, overflow-proof,
    /// and always producing a file Excel accepts. Shared by the shape and
    /// chart gradient builders so their angle handling stays consistent.
    /// </summary>
    public static int GradientAngleToOoxmlUnits(int degrees)
    {
        var normalized = ((degrees % 360) + 360) % 360;
        return normalized * 60000;
    }

View on GitHub (pinned to 1ced45e900)

Solutions

  1. Reduce the angle modulo 360 before submitting, or keep it within [-3600, 3600] degrees.
  2. Confirm the value is in degrees, not radians (radians*180/pi).
  3. Do not confuse with Excel text rotation (SafeParseUint, 0-180) — this is the PPT/shape degree rotation.

Example fix

// before
rotation="9999"
// after
rotation="279"   // 9999 % 360
Defensive patterns

Strategy: validation

Validate before calling

static bool IsValidRotationDegrees(string value)
{
    return double.TryParse(value, System.Globalization.NumberStyles.Float,
               System.Globalization.CultureInfo.InvariantCulture, out var d)
           && !double.IsNaN(d) && !double.IsInfinity(d)
           && d >= -3600 && d <= 3600;
}

Prevention

When it happens

Trigger: Calling PPT add shape/group/connector or Set shape/group with rotation outside [-3600, 3600], e.g. rotation="9999", rotation="-5000", or rotation="3601".

Common situations: Passing radians by mistake (e.g. '6.28' is fine, but '6280' is not); typing a full-circle value like '7200'; computing rotation from a formula that did not mod-360; confusing this PPT degree input with Excel's separate 0-180 uint rotation.

Related errors

AI-assisted analysis of iOfficeAI/OfficeCLI@1ced45e900 (2026-08-13). Data as JSON: /api/errors/40059a0fe5b6c4a7. Report an issue: GitHub.