Using svg.draw(pen) and parse_path() from svgLib threw exception
ValueError: could not convert string to float: 'a'
on a SVG <path> string generated by Inkscape. Altering the path
string might object to other string bits like 'Z' or 'v', or
give even stranger exceptions.
Finally tracked it down to the path containing particular valid
numbers like "-4e-5" or "1e-4". Changing these to "-4.0e-5" or
"1.0e-4" would stop the exceptions. The parse_path() was not
accepting valid SVG real numbers.
The specification for real number formats is a bit of a mess in
CSS land right now, but the reassuringly concrete spec is:
https://www.w3.org/TR/css-syntax-3/#number-token-diagram
which allows a real number having an exponent but without having
a fractional part, such as the number "1e3".
This change updates an RE to make fractional parts optional,
and adds a test for this valid SVG number format.
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
