It has been brought to my attention that svgelements violates error handling section 9.5.4 of the SVG spec. That when a malformed svg path is sent the SVG should still parse up to the point of the error and return that faulty path. However, due to using a parse function unattached to objects the ability to return an error and the object is severely hampered. If you, however, declared a Path() then called path.parse(), an error could be thrown while still modifying the current path. This could be done to produce partial paths.
Furthermore, without this same mechanism in the SVG class directly, we hit the same issue of not returning both the error and the object. So if we introduce an on_error mechanism to the parse() function we can choose the operation. We currently 'ignore' errors that are found within the parsing. However, we could equally raise those error directly for the end-user, or stop parsing when we reach an error while parsing.
This does not, however, provide both the error and the parsed value. To do that we'd need to already have an SVG object and be running a parse function on that svg object (we currently run staticmethod parse() which is on the SVG class itself). At this point is is not clear we can easily do both. We can also, sometimes, due to bad svg files have a group as the outermost object and so parse() will return a group. This behavior would be impossible if we already constructed the SVG and parsed the class as a secondary operation.
See #217
It has been brought to my attention that svgelements violates error handling section 9.5.4 of the SVG spec. That when a malformed svg path is sent the SVG should still parse up to the point of the error and return that faulty path. However, due to using a
parsefunction unattached to objects the ability to return an error and the object is severely hampered. If you, however, declared a Path() then called path.parse(), an error could be thrown while still modifying the current path. This could be done to produce partial paths.Furthermore, without this same mechanism in the SVG class directly, we hit the same issue of not returning both the error and the object. So if we introduce an
on_errormechanism to theparse()function we can choose the operation. We currently 'ignore' errors that are found within the parsing. However, we could equally raise those error directly for the end-user, or stop parsing when we reach an error while parsing.This does not, however, provide both the error and the parsed value. To do that we'd need to already have an SVG object and be running a parse function on that svg object (we currently run staticmethod parse() which is on the SVG class itself). At this point is is not clear we can easily do both. We can also, sometimes, due to bad svg files have a
groupas the outermost object and soparse()will return a group. This behavior would be impossible if we already constructed the SVG and parsed the class as a secondary operation.https://www.w3.org/TR/SVG2/paths.html#PathDataErrorHandling