SVG conversion architecture change

This is a change towards a new architecture for SVG conversion according to #54.

The reason why I want to make this change is kind of the same reason I took time before to create the parser architecture:

• different parts of conversion (path, style, live-shape, ...) can be tested independently because there is loose coupling between the components
• we can reach a high test coverage (I mean more than line-coverage: complexity coverage)
• while implementing different features, it becomes clear that the current way of converting to SVG comes with subtle problems:
  • it is not clear where to formulate some of the responsibilities:
  • Before this MR there is state that influences the meaning of AIElements (e.g. u can be a group or a way a compound path is modified) and that has no place the be addressed. This worries me as the discrepancy can lead to a lot of special cases and side effects. This MR proposes a solution e.g. by adding a state machine (WIP)
• Bonus: polymorphy adds an extra bit of flexibility and ease of use

My hope is that with this change, although it takes a while to think about it, the same happens as with the parser: the complexity is captured in explicit places and the future SVG conversion features can be written in a very descriptive way, almost like a DSL (Domain Specific Language). An example is in the parser where inkai.parser.lazy.generate_eol() can be used now to create documented commands in a few lines.

At the point of opening the MR, the code is still messy and I have written some more (not pushed) to become clearer about how to approach it. I am asking for a bit of patience, knowing that this is not the best time: The contract has ended and features are still not implemented. I know, Jonathan and I would probably approach this change in different ways. So, it is important to communicate this well.

I hope, you can be patient with me. I will be patient with your decision for part two. I value taking the time that it needs to come to a conclusion that is not rushed and supported by those taking it. From my side, I do not expect a decision about part 2 before August as in my experience all matters involving the SFC are slow but steady.

My prediction is that this is the last mayor change of architecture (first one was the parser) that creates flexibility and extensibility on the SVG conversion side while respecting all the constraints listed in #54. I am looking forward to completing this PR soon, writing a blog post and more conversations.

If you like, you can have a look at the code but it is probably more efficient to do that once I completed the core as I did not tidy up, yet!

PS: I celebrate the high test coverage because that means that this change can be approached without loss of features.

Changes

Checklist

• Change is tested

• Change is documented.

• Licenses are up to date

Related