I don't know this code, but I think it could have more descriptions such as:

• what are those numbers 7, 3, 4;
• what is each command;
• where that ReadFlagTest is being used ...

+1 for adding test cases. I would maybe add a test for the case you mentioned 'a3.04 3.04 0 00.123-.463' and see if it parses it correctly.

Is the a command the only one that uses flags? If there are more it might not be a good idea to handle it like this. Otherwise, I think it's fine.

In D10433#262798, @Germano Cavalcante (mano-wii) wrote:

I don't know this code, but I think it could have more descriptions such as:

• what are those numbers 7, 3, 4;
• what is each command;
• where that ReadFlagTest is being used ...

Yes, I agree, I've just followed the style of the previous code. I will add comments about '7' (number of arc command arguments), '3, 4' (positions of flag arguments in arc commands), but before, can you be more specific about 'what is each command' and 'where that ReadFlagTest is being used'? I think that each command is properly documented in SVG 1.1 and 2.0 specifications, wouldn't it be too much of a stretch to redocument all the commands in this addon?

+1 for adding test cases. I would maybe add a test for the case you mentioned 'a3.04 3.04 0 00.123-.463' and see if it parses it correctly.

Is the a command the only one that uses flags? If there are more it might not be a good idea to handle it like this. Otherwise, I think it's fine.

Yes I agree adding 'whole parsing' tests, I will add it. The arc command is the only one that uses flags, I've see other times this way of handle that case in other open source SVG parsers.

@Germano Cavalcante (mano-wii) I agree with @Álvaro Mondéjar (mondeja) . I would maybe link to the command documentation but not copy the docs (since there is quite a lot to document).

In D10433#262816, @Álvaro Mondéjar (mondeja) wrote:

Can you be more specific about 'what is each command' and 'where that ReadFlagTest is being used'? I think that each command is properly documented in SVG 1.1 and 2.0 specifications, wouldn't it be too much of a stretch to redocument all the commands in this addon?

I don't know the code and just took a quick look.
But if it is interesting to have a description for the commands, in my opinion the comment could be something like this "#Conform to the description of the commands seen at https://www..."

Apparently the description of the tests in the svg_util_test.py file are in the functions they call (in svg_util.py).
I was just a little confused since I didn't know it was a test code (since the purpose of the patch is to fix something?)

Perhaps the test code could be in a separate patch.

+1 for adding test cases. I would maybe add a test for the case you mentioned 'a3.04 3.04 0 00.123-.463' and see if it parses it correctly.

I am not very familiar with the Blender testing system, how can I import something from the module import_svg.py running the test suite as a standalone Python script if the bpy module only exists inside Blender? Without that I can't test SVGPathData class...

Perhaps the test code could be in a separate patch.

Just let me know, I don't know exactly how addons are tested.

This change seems to had been included in 2.93.5.

Thank you all for the great work!