Missed this test in previous commit.
Test is testing that parsing extraction of individual parameters
works as specified when spaces are omitted. Such as signaled when
a new number is specified with a leading sign +/-
Test previously used
"M1-2A3-4-1.0 01.5.7",
where the first arc radius value was '3' and the second was '-4'.
Now that we are forcing radius values to be non-negative using abs()
the value returned in the test is not
("arcTo", (3.0, -4.0, -1.0, False, True, (0.5, 0.7))),
but rather
("arcTo", (3.0, 4.0, -1.0, False, True, (0.5, 0.7))),
Changed to expect the positive value, nicely the test continues to
test omitting spaces, but now also tests that negative radius values
are forced non-negative.
If a font has SinglePosFormat2 subtable with ValueFormat=0, then it contains a Value list with all None values.
Even though we don't build such inefficient tables, they do exist in the wild, as #2602 demostrates so we should handle those nicely, by downgrading them to Format1 with a single None value
SVG documentation has an explicit requirement that _consumers_
of path arc commands accept and *correct* certain bad values.
This includes using the absolute value of the arc command's rx
and ry radius parameters.
See "9.5.1. Out-of-range elliptical arc parameters"
https://www.w3.org/TR/SVG/paths.html#PathDataEllipticalArcCommands
Lib\fontTools\svgLib\path\parser.py is missing any guard against
negative values for rx and ry parameter. Adding an abs() to each
value read will implement the SVG specification.
A problem was seen here while most programs and browsers handle
bad arc commands just fine. A bug report has been registered with
Inkscape (!) to protect any other non-SVG compliant programs.
See https://gitlab.com/inkscape/inbox/-/issues/6857 for more details.
if explicitly enabled, it will raise ImportError if uharfbuzz is not found, and will propagate the uharfbuzz error instead of silently falling back to the pure-python serializer
