Closed morpho-matters closed 1 year ago
<svg width="240" height="320" viewBox="-5 -5 10 10" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M 0,0 C -2,-3 -1,-4 0,-3" stroke="#FFC681" stroke-width="0.05px"/>
<rect x="0" y="0" width="1.1547005383792515" height="3.0" transform="scale(-1,-1)" stroke="#FFC681" stroke-width="0.05px"/>
</svg>
Confirmed. That bit seems quite clearly not correctly the bounding box.
This is an edge case when p1 - (3 * p2) + (3 * p3) - p4 == 0
In this case for y our values are 0, -3, -4, -3. Which gives us 0 - (3 * -3) + (3 * -4) - -3
which is 0 + 9 - 12 + 3
which does equal 0
. In this case we have a division-by-zero numerical instability which we avoided providing the extrema, but here the extrema was actually the right answer.
Given that we're solving a*t² + b*t + c
in a case where a = 0, we actually solve 0 = b*t + c
(assuming b doesn't also equal 0). When we apply the quadratic formula the division by 2*a
is a problem when a is zero. So we fallback to solving the easier problem if we know a==0.
This may be related to #186, but thought I'd bring it up in case it isn't known about. The computed bounding box of certain cubic beziers seems to be incorrect sometimes. Here's an example:
This outputs![bad-bbox](https://user-images.githubusercontent.com/37314443/217055876-2ba213d4-03e0-4206-882e-4e58ab04895a.png)
(-1.1547005383792515, -3.0, 0.0, 0.0)
, butymin
should really be lower than-3
. Here is a picture of the bezier with the incorrectly computed bounding box:svgelements version: 1.9.0 Python version: 3.8.1 OS: Windows