Bugzilla

(In reply to Daniel Holbert [:dholbert] from comment #9)
> We seem to be scaling things down a bit more than we should be, for some reason (and by a bit more than floating-point-error would trigger....)

Ah right, that's because we don't represent zoom as floating-point -- we represent it as a 16-bit fixed-point value, with range from 0 to 1023.984375, per https://searchfox.org/mozilla-central/rev/c25dbe453ff9ca10f2c6bdfb873893c515a29826/servo/components/style/values/computed/box.rs#121-129

So that's why:
(a) we're getting values that aren't quite exact (sometimes over/undershooting in testcase 4)
(b) we end up with fixed-point values that happen to convert to "unlucky" floating-point values which scale app-units in a way that produces fractional app-units, which need to be rounded in ways that might cause things to not fit and hence linewrap, as in testcases 1-3.

(In reply to Daniel Holbert [:dholbert] from comment #9)
> We seem to be scaling things down a bit more than we should be, for some reason (and by a bit more than floating-point-error would trigger....)

Ah right, that's because we don't represent zoom as floating-point -- we represent it as a 16-bit fixed-point value, with range from 0 to 1023.984375, per https://searchfox.org/mozilla-central/rev/c25dbe453ff9ca10f2c6bdfb873893c515a29826/servo/components/style/values/computed/box.rs#121-129

So that's why:
(a) we're getting values that aren't quite exact (sometimes over/undershooting in testcase 4)
(b) we end up with fixed-point values that happen to convert to "unlucky" floating-point values which scale app-units in a way that produces fractional app-units, which need to be rounded in ways that might cause things to not fit and hence linewrap, as in testcases 1-3 (presumably in the fixed-point-zoom --> float --> nscoord arithmetic that happens [here](https://searchfox.org/mozilla-central/rev/c25dbe453ff9ca10f2c6bdfb873893c515a29826/layout/style/ServoStyleConstsInlines.h#1204-1208)),