@Panchromatic
That was a nice exercise!
I looked for a pattern in the numbers:
0.2 = 13107
0.5 = 32768
0.7 = 45875
1.0 = 65536
1.5 = 98304
1.7 = 111411
2.0 = 131072
I then reverse-engineered that into the following, which appears to work consistently:
/*
https://community.adobe.com/t5/photoshop-ecosystem-discussions/get-the-clipping-path-flatness/td-p/14953621
*/
alert("Clipping Path Flatness: " + getClippingPathFlatness() + " device pixels");
function getClippingPathFlatness() {
var ref = new ActionReference();
ref.putEnumerated(charIDToTypeID("Dcmn"), charIDToTypeID("Ordn"), charIDToTypeID("Trgt"));
var desc = executeActionGet(ref);
var clippingPath = desc.getObjectValue(charIDToTypeID("Clpg"));
// 65536 = 1.0 as the internal programming value, range of 0.2 - 100 scale in device pixels
return (clippingPath.getInteger(charIDToTypeID("ClpF")) / 65536).toFixed(1);
}
Edit: Not being a programmer, I asked AI why 65536 was significant and this was the reply –
In programming, especially when dealing with digital graphics and certain encoding schemes, 65536 might represent 1.0 due to fixed-point arithmetic or specific scaling conventions.
Here's the scoop: 65536 is 2^16, or a number representing the range of values in 16-bit systems. When graphics systems use 16-bit fixed-point numbers, 65536 is often the scaling factor to move between integer representation and floating-point representation.
So, in your context, the value 65536 could be representing the normalized floating-point value 1.0. This mapping ensures precision in representing and manipulating values within the limited range of an integer but allows for smooth transitions when converting to floats. It's a nifty way to ensure compatibility and precision.