Week 2: First SVG Export, Design Discussions, and Building the Pipeline
Hey everyone!
The previous weeks have been going really well, and this week was the first time I started writing some real code for the SVG export project.
After setting up the new addon project and spending time understanding the existing architecture, I started implementing the design we had been discussing. Before writing code, we had already identified several edge cases through community feedback and earlier discussions, so a lot of the work this week was focused on making sure the architecture could handle those cases in the future.
First of all, thank you to everyone who shared feedback and ideas. Many of the discussions helped reveal problems that would have been much harder to discover later in development.
Starting Small: One Shape First
Rather than trying to support every shape at once, I decided to start with a single shape: circles.
While exploring the codebase, I realized that circles, rectangles, lines, and many other primitives all pass through the same Shape system. Because of that, it didn't make sense to immediately start modifying code for every shape individually.
Instead, my goal was to build the entire export pipeline around a single shape first and verify that the architecture worked end-to-end.
So I started with a flat recording structure.
The idea was simple:
Record the shape.
Pass it through the export pipeline.
Generate SVG output.
Verify that the output matched expectations.
And it worked!
I successfully exported my first SVG shape from the new pipeline, which was a pretty exciting milestone.
From Flat Recording to Hierarchical Recording
Once the basic pipeline was working, I started looking at transformations.
As soon as transforms entered the picture, it became clear that a flat recording structure would not be enough for the long term.
This led to work on a transform stack and a transition from a flat recording model toward a more hierarchical structure.
The recording format is still evolving, and we're actively discussing how it should look in its final form. The goal is to find a representation that is flexible enough to support SVG export while also remaining maintainable as more features are added.
Right now the recorder looks something like this:
Root
├── Transform Group
│ ├── Circle
│ ├── Rectangle
│ └── Line
└── Transform Group
└── Circle
This is likely to change as development continues, but it gives an idea of the direction we're exploring.
Choosing a DOM-Based SVG Generator
Another design decision we made was to use a DOM-based approach for SVG generation.
Instead of manually constructing large SVG strings, we create and manipulate SVG DOM elements directly and then serialize the final document.
So far this approach feels much cleaner and easier to maintain. It also makes it simpler to manage nested groups, transforms, and future SVG-specific features.
Lots of Design Discussions
One thing I've learned from this project is that writing code is only part of the work.
A significant amount of time this week was spent discussing design decisions with my mentor.
We've been continuously refining:
How recording should work
How transformations should be represented
How SVG generation should be structured
How future shapes will fit into the pipeline
How to handle edge cases discovered through testing
The design is still evolving, and honestly that's expected. Building the right architecture early can save a lot of pain later.
If you're interested, you can also check out the design document and ongoing discussions. The implementation is following that document closely, but the document itself is still very much a living document.
Feel free to explore the code, open issues, suggest improvements, or follow along as the exporter develops.
Community Feedback and Hidden Line Removal
This week I also spent some time looking into community feedback around hidden line removal.
Hidden line removal is an interesting problem because it sits at the intersection of rendering and geometry processing. We discussed several approaches and identified a potential direction for supporting it in the future.
It's still early, but these conversations are helping shape how we think about the exporter beyond basic SVG generation.
The Background Problem
Another topic that generated a lot of discussion was background handling.
At first glance, background seems simple.
Then you start asking questions:
What happens with multiple background calls?
How should transparent backgrounds behave?
How should clear() interact with exported content?
Should background be treated as a property or as a recorded operation?
The more we discussed it, the more complexity we uncovered.
This is still an active design topic, and we're continuing to evaluate different approaches before locking anything down.
Looking Ahead
For the next week, my focus will be on testing.
One thing we've realized is that we're currently lacking comprehensive tests, and now is a good time to start building them before the project grows larger.
I'll also begin thinking about SVG import support. The current focus remains export, but import is something we want to keep in mind while making architectural decisions so we don't accidentally paint ourselves into a corner.
Feedback Welcome
That's all for this week's update!
As always, I'd love feedback from the community.
How do you currently use SVGs in your workflow?
What SVG-related edge cases have caused problems for you in the past?
Are there any design decisions you think we should reconsider?
What features would you expect from a modern SVG export/import system?
Feel free to share your thoughts. Every discussion so far has helped improve the project, and I'm excited to keep sharing progress as development continues.
See you in next blog
