Marc EdwardsmacOS 15 vs macOS 26 mouse cursors.
The info.plist files accompanying the macOS cursors are interesting. They have the shadow values (shadows are drawn at runtime and not included in the cursor PDFs). They’re also full of rounding errors, which makes me thing they were generated by a tool. A human probably typed 0.033 and 0.45, and rounding errors caused the issue in the screenshot.
Eelco Lempsink@marcedwards Don’t think those are rounding errors, just an effect of the way that floats are represented in binary. So a human indeed probably entered the values you said, but these representations easily parse to the right binary representation that is closest to that number.
@eelco Sure. By “rounding errors” I meant float to string conversion for the JSON, or anything related. It’s clear the JSON wasn’t human authored.
@marcedwards Try this in the terminal:
> echo '{"test":0.45}' > test.plist
> plutil -convert xml1 test.plist
> cat test.plist
As you can see, the way floats are stored in the XML serialization has nothing to do with how artisanal the original JSON was.
Bonus points: edit the XML version back to 0.45 and run the convert command again.
@eelco Nice! Not entirely sure what you’re saying though. You’re saying 0.45 can’t actually be represented as a double, right? https://www.binaryconvert.com/result_double.html?decimal=048046052053
My comment was that the JSON was authored by a tool, not a human.
@marcedwards Yes correct. My reaction was to your initial statements:
“They’re also full of rounding errors, which makes me thing they were generated by a tool.”
Not errors, and yes plist files are not intended to be hand authored and will generally go through a check / formatting step.
“A human probably typed 0.033 and 0.45, and rounding errors caused the issue in the screenshot.”
This is not true because they are not errors / issues.
Apologies for being a reply-guy! 🙈
@eelco All good! I didn’t choose the best way to describe it. Is there a better phrase? “Impossible values to be represented by a double” is probably better? I guess the value was still rounded to the closest it can be, so… that is a rounding error of sorts? You may know this, but there’s float to string conversion libraries that don’t have this issue.