Exporting to KiCad can allow integration into a larger PCB flow, and maybe also provide quick-but-dirty pathways to fabrication outputs (eg, gerbers, pick-and-place position files).
One short term use case that could make a lot of sense is where SVG-PCB can be used to design layout snippets (for subcircuits, especially parameterized ones like a keyboard switch matrix) that then gets integrated into a larger PCB which has a lot more one-of routing (eg, microcontroller). Or even autorouting the rest of the board.
Recapping our earlier discussion with a few more technical details:
It seems that .kicad_pcb files contains a copy of the full footprint data for all components.
A simple solution here might be to export what SVG-PCB has for that footprint - even if it's barebones (eg, just the copper layers). As long as the footprint library name is intact, the user should be able to do a update-footprints-from-library from KiCad and revert to the original (full) footprint.
Alternatively, maybe the source KiCad footprint data can be stored as metadata? But this might cause problems if the footprint source isn't KiCad, so you'll probably need to fall back to the above anyways.
The KiCad PCB file contains a netlist. You might be able to get away with just skipping the net field, and rely on the user updating from schematic / netlist from within KiCad.
KiCad seems to be pretty decent (eventually - might take a few reloads) about updating existing tracks from a new netlist, even if the net names change.
Components have a refdes, tedit, tstamp, and path. path defines a hierarchical path (formatted as GUIDs) that is imported from a netlist, I think this is the important one when updating from a netlist in match-by-timestamp mode. Might be able to get away with omitting tedit and tstamp.
There should be some way to optionally specify this path value for components in SVG PCB. This will probably be more used by those working with generated netlists where there is control over the path value, instead of schematic-based flows where path is arbitrarily assigned by the schematic editor.
After the layout is exported from SVG PCB, these flows might work to integrate it into a larger board:
KiCad has an 'append board' feature, which seems to preserve component path and refdes of the imported board. This does not deduplicate components, if the same components exist in both the target and imported board (so the user will need to delete duplicates manually - potentially assisted by select-hierarchy). This seems to be the most promising short-term solution.
Copy-pasting components between boards does not preserve path and will be deleted if updated from netlist in match-by-timestamp mode.
The Save-Restore Layout KiCad plugin allows component positions and some routing to be saved in a separate file and loaded into a new board. There's currently a check in place that requires a schematic so this isn't a option right now. But in the future, if the plugin can support schematic-less flows, it might be an option for SVG-PCB to generate this saved-layout file that can be loaded in-place into an existing board.
Exporting to KiCad can allow integration into a larger PCB flow, and maybe also provide quick-but-dirty pathways to fabrication outputs (eg, gerbers, pick-and-place position files).
One short term use case that could make a lot of sense is where SVG-PCB can be used to design layout snippets (for subcircuits, especially parameterized ones like a keyboard switch matrix) that then gets integrated into a larger PCB which has a lot more one-of routing (eg, microcontroller). Or even autorouting the rest of the board.
Recapping our earlier discussion with a few more technical details:
netfield, and rely on the user updating from schematic / netlist from within KiCad.tedit,tstamp, andpath.pathdefines a hierarchical path (formatted as GUIDs) that is imported from a netlist, I think this is the important one when updating from a netlist in match-by-timestamp mode. Might be able to get away with omittingteditandtstamp.pathvalue for components in SVG PCB. This will probably be more used by those working with generated netlists where there is control over thepathvalue, instead of schematic-based flows wherepathis arbitrarily assigned by the schematic editor.After the layout is exported from SVG PCB, these flows might work to integrate it into a larger board:
pathand refdes of the imported board. This does not deduplicate components, if the same components exist in both the target and imported board (so the user will need to delete duplicates manually - potentially assisted by select-hierarchy). This seems to be the most promising short-term solution.pathand will be deleted if updated from netlist in match-by-timestamp mode.