PCBmodE has custom commands for shapes defined in JSON and converts them into SVG paths, factoring all transformations; it doesn't use SVG commands that would otherwise result in the same appearance of shapes in the resulting SVG.
So, for example, PCBmodE will take its own rect type with its width and height definitions and create a path to represent it.
{
"type": "rect",
"style": "stroke-width:0.05;",
"width": 100,
"height": 100,
"transform": "translate(44,22) rotate(55,6,7) scale(2)"
}It doesn't use SVG's <rect ... />.
A reasonable question would be why do it that way when we can construct the SVG file with SVG commands. It could be easier and simpler that way.
Let's see what's happening in the design process. We create the SVG and then it needs to be converted into Gerber, a non-vector point-to-point format that's very old but the most common exchange format for PCB manufacture. What this means in practice is that each shape needs to be converted to a path and then 'linearised'. PCBmodE does the convert-to-path for the SVG instead of doing it after the SVG.
The reason is that I wanted the SVG to display what's closest to the end result, after the convert-to-path, so that potential conversion problems could be detected at the SVG stage and not at the Gerber stage. This helps with usability because you only need to look at one thing while designing.
PCBmodE has custom commands for shapes defined in JSON and converts them into SVG paths, factoring all transformations; it doesn't use SVG commands that would otherwise result in the same appearance of shapes in the resulting SVG.
So, for example, PCBmodE will take its own
recttype with itswidthandheightdefinitions and create a path to represent it.{ "type": "rect", "style": "stroke-width:0.05;", "width": 100, "height": 100, "transform": "translate(44,22) rotate(55,6,7) scale(2)" }It doesn't use SVG's
<rect ... />.A reasonable question would be why do it that way when we can construct the SVG file with SVG commands. It could be easier and simpler that way.
Let's see what's happening in the design process. We create the SVG and then it needs to be converted into Gerber, a non-vector point-to-point format that's very old but the most common exchange format for PCB manufacture. What this means in practice is that each shape needs to be converted to a path and then 'linearised'. PCBmodE does the convert-to-path for the SVG instead of doing it after the SVG.
The reason is that I wanted the SVG to display what's closest to the end result, after the convert-to-path, so that potential conversion problems could be detected at the SVG stage and not at the Gerber stage. This helps with usability because you only need to look at one thing while designing.