In the special case of contrasty content being present around the element border, the contents and the element size can differ by about 1px:
When editing with sparse aesthetics such as these beautiful shapes with low-ink borders (Tufte!) a constancy would be nice even if not technically critical.
Based on a discussion with @cqliu1 about the potentially related LINK REDACTED a guess is that the shape size integers and the layouting element size integers are determined using a different function (eg. Math.round vs Math.floor). Maybe the solution is for the shape to adhere to the actual element size from layouting so that the float->integer conversion happens only in one place, and if it changes, the shape code doesn't need to change in sync.
The history of element size truncation in layouting is an issue reported by I believe @rashidkpc which observed that non-integral widths/heights result in blurred text pieces in the element contents.
Original comment by @monfera:
In the special case of contrasty content being present around the element border, the contents and the element size can differ by about 1px:
When editing with sparse aesthetics such as these beautiful shapes with low-ink borders (Tufte!) a constancy would be nice even if not technically critical.
Based on a discussion with @cqliu1 about the potentially related LINK REDACTED a guess is that the shape size integers and the layouting element size integers are determined using a different function (eg.
Math.round
vsMath.floor
). Maybe the solution is for the shape to adhere to the actual element size from layouting so that the float->integer conversion happens only in one place, and if it changes, the shape code doesn't need to change in sync.The history of element size truncation in layouting is an issue reported by I believe @rashidkpc which observed that non-integral widths/heights result in blurred text pieces in the element contents.