You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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 itswidth
andheight
definitions and create a path to represent it.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.
The text was updated successfully, but these errors were encountered: