Seeking ideas on layer handling with symbols
Hi, I'm currently working on a GSoC proposal to add PCB layout and schematics editing capabilities to Inkscape (it's not as hard as it sounds). In a PCB layout, you have a number of (physically stacked) layers (one copper layer on each side of the board, possibly multiple copper layers *inside* the board, green solder mask on both sides on top of the copper layers and white print on top of the solder mask for markings etc.). I'm currently unsure on how to map these layers to SVG.
It appears obvious to map these to Inkscape layers/SVG groups. This does not work too well however, since all components on the board span multiple layers (pads for the pins on the copper layer, cut-outs for the pads on the solder mask and a package outline and part id/number on the silkscreen). If a component is moved, all parts of it (on any layers) need to be moved simultaneously, and in fact, normally it does not make sense to even select the parts of a component individually.
My problem is that this would essentially require cross-group groups, i.e. groups whose elements can be elements of other groups not part of the group, which clashes with XML's tree structure.
Currently, I have two and a half ideas on how to address this issue:
1) I implement PCB layers as something different to Inkscape's layers that is just denoted by an object property (I don't like this). This attribute would be pretty similar to the z-order attribute that will be include in SVG 2. 2) I find some way of "linking" multiple groups on multiple layers (I don't like this either, it's easier but more "hackish").
I'm currently leaning towards the second option since I can imagine the first will require a *lot* of work (though I will still look into that further).
Perhaps you have some ideas on how this could be implemented in pre-2.0 SVG.
Thanks, Sebastian
Hi Sebastian.
For PCBmodE I use Inkscape layers for PCB layers ("top", "bottom") and what I call "sheets" ("soldermask", "silkscreen", "documentation", etc.) in order to avoid confusion. I also use hierarchy of layers so I can completely hide the top/bottom layer and so on.
Here's an example SVG PCBmodE generated:
https://bitbucket.org/boldport/pcbmode/downloads/shimmy_rev_A_1.svg
(I cleaned up a lot of things since that SVG was generated, and there's still work on that front ;)
I tried to solve the problem you describe in several ways, but couldn't find anything that wasn't a huge hack. (Worth mentioning is that I've decided to use Inkscape without modification up to now.) My current solution for movement of components is to only move the copper pads (which are grouped) and then when I next generate the board, the new coordinates are extracted, and then all the other layers/sheets are placed in the new location. It's not perfect but it works for me for now.
cheers, saar.
On Tue, May 7, 2013 at 10:42 AM, Sebastian Götte <jaseg@...2974...>wrote:
Hi, I'm currently working on a GSoC proposal to add PCB layout and schematics editing capabilities to Inkscape (it's not as hard as it sounds). In a PCB layout, you have a number of (physically stacked) layers (one copper layer on each side of the board, possibly multiple copper layers *inside* the board, green solder mask on both sides on top of the copper layers and white print on top of the solder mask for markings etc.). I'm currently unsure on how to map these layers to SVG.
It appears obvious to map these to Inkscape layers/SVG groups. This does not work too well however, since all components on the board span multiple layers (pads for the pins on the copper layer, cut-outs for the pads on the solder mask and a package outline and part id/number on the silkscreen). If a component is moved, all parts of it (on any layers) need to be moved simultaneously, and in fact, normally it does not make sense to even select the parts of a component individually.
My problem is that this would essentially require cross-group groups, i.e. groups whose elements can be elements of other groups not part of the group, which clashes with XML's tree structure.
Currently, I have two and a half ideas on how to address this issue:
- I implement PCB layers as something different to Inkscape's layers that is just denoted by an object property (I don't like this). This attribute would be pretty similar to the z-order attribute that will be include in SVG 2.
- I find some way of "linking" multiple groups on multiple layers (I don't like this either, it's easier but more "hackish").
I'm currently leaning towards the second option since I can imagine the first will require a *lot* of work (though I will still look into that further).
Perhaps you have some ideas on how this could be implemented in pre-2.0 SVG.
Thanks, Sebastian
Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, 2013-05-07 at 11:42 +0200, Sebastian Götte wrote:
Perhaps you have some ideas on how this could be implemented in pre-2.0 SVG.
I've been working on symbols... I don't know if you're really going to be using clones/symbols <use> tags. But don't forget to resolve your objects when parsing.
If it were me, I'd simply prefix the id somehow. It sounds hackish at first but I don't think it is as it fits existing svg, provides a more precise identity which you can use to identify the elements in code.
This kind of meta-type is out of scope for svg itself and even for inkscape. If you were to do some attributes, then a wouldn't a separate namespace be the best way?
Layers and groups are designed for _editing_ a set of objects and allowing transforms on them. Since this isn't want you need, the group/layers in svg are not related to your PCB layers.
Martin,
Purely a thought experiment:
Say I had a group of objects called "pins". I give them a property called "depth" and assign a value of N. Then I include the "pins" group inside another called "chip" with no custom depth. At output time, a final set of layers is created by parsing all of the objects and copying them to the output layers. Objects with a custom "depth" attribute like the "pins" group would be output to N-1 layers below the input layer, along with the corresponding output layer.
Or how about a set of named colors? EG, "registration" color outputs to every layer, etc.
I'm probably over-simplifying, but I face some similar issues when preparing screen prints: some objects need to exist on multiple screens (in exactly the same position). I end up doing a lot of back-and-forth between layers, pasting in place, spot colors (ie, I manage it all by hand - but it's not as bad as it sounds, I assume a PCB is going to be more painful though).
If this is way off base, feel free to ignore ;)
Chris
Chris
On 05/07/2013 01:34 PM, Martin Owens wrote:
If it were me, I'd simply prefix the id somehow. It sounds hackish at first but I don't think it is as it fits existing svg, provides a more precise identity which you can use to identify the elements in code. [...] Layers and groups are designed for _editing_ a set of objects and allowing transforms on them. Since this isn't want you need, the group/layers in svg are not related to your PCB layers.
On 05/07/2013 07:41 PM, Chris Mohler wrote:
Say I had a group of objects called "pins". I give them a property called "depth" and assign a value of N. Then I include the "pins" group inside another called "chip" with no custom depth. At output time, a final set of layers is created by parsing all of the objects and copying them to the output layers. Objects with a custom "depth" attribute like the "pins" group would be output to N-1 layers below the input layer, along with the corresponding output layer.
Or how about a set of named colors? EG, "registration" color outputs to every layer, etc.
Perhaps I could use a topology like this: <g inkscape:label="Layer 1" inkscape:groupmode="layer" id="pcb_top"> <g id="some_part" class="pcb_component"> <g class="pcb_layer_copper"> [...] </g> <g class="pcb_layer_soldermask"> [...] </g> <g class="pcb_layer_silkscreen"> [...] </g> </g> </g> This way I don't need to introduce any new attributes, I'm still using SVG groups like they were intended to be used and it maps OK to SVG's object order-based drawing. Since components on one layer normally do not overlap (at least in PCB design), the 'id="some_part" class="pcb_component"' group does not pose a problem. Since components on both sides of the PCB may overlap, I would organize each side into one Inkscape layer. PCB traces will have to be inserted at the bottom (not top) of the respective (Inkscape) layer not to overlap solder mask or silk screen drawings.
When SVG2 comes about, the classes can simply be assigned z-order attributes via CSS.
On 2013-05-07 11:42 +0100, Sebastian Götte wrote:
Hi, I'm currently working on a GSoC proposal to add PCB layout and schematics editing capabilities to Inkscape (it's not as hard as it sounds). In a PCB layout, you have a number of (physically stacked) layers (one copper layer on each side of the board, possibly multiple copper layers *inside* the board, green solder mask on both sides on top of the copper layers and white print on top of the solder mask for markings etc.). I'm currently unsure on how to map these layers to SVG.
It appears obvious to map these to Inkscape layers/SVG groups. This does not work too well however, since all components on the board span multiple layers (pads for the pins on the copper layer, cut-outs for the pads on the solder mask and a package outline and part id/number on the silkscreen). If a component is moved, all parts of it (on any layers) need to be moved simultaneously, and in fact, normally it does not make sense to even select the parts of a component individually.
My problem is that this would essentially require cross-group groups, i.e. groups whose elements can be elements of other groups not part of the group, which clashes with XML's tree structure.
Currently, I have two and a half ideas on how to address this issue:
- I implement PCB layers as something different to Inkscape's layers that is just denoted by an object property (I don't like this). This attribute would be pretty similar to the z-order attribute that will be include in SVG 2.
- I find some way of "linking" multiple groups on multiple layers (I don't like this either, it's easier but more "hackish").
I'm currently leaning towards the second option since I can imagine the first will require a *lot* of work (though I will still look into that further).
Perhaps you have some ideas on how this could be implemented in pre-2.0 SVG.
Maybe worth-while a closer look (even though the fork will no longer be maintained or enhanced anymore [1]):
The 'ponyscape' fork of Inkscape implemented a tagging system in v0.4 which allows to tag objects, and a selection method based on the tag (across layers and across groups) i.e. it adds a concept of selection sets (for editing, exporting etc.). It does not treat objects with the same tag as a 'pseudo'-group though (which would for example apply an auto-transform (e.g. translate) to all objects with the same tag):
<quote> Tagging system!!
This system allows you to assign any number of tags to objects (paths, groups, etc.). If you select a tag within the dialog (ctrl-t), it will select all items which have that tag. To use the dialog, you must first create a tag using the + button. You can rename tags by double clicking on their name, and you can drag and drop tags to reorder or nest them. To assign a tag to an object, select the object and then click the + button next to the tag name in the list. To remove a tag from the list, select it under the "Items" node and press the delete key. This is especially useful for shading as you can tag all of your shading objects and in 2 clicks make them visible or hidden. (...) </quote> http://ponyscape-vectors.deviantart.com/journal/Ponyscape-v0-4-351369830
Sample screenshot: http://fc04.deviantart.net/fs71/f/2013/028/7/a/4_by_flutterguy317-d5t3tuv.png
[1] project is currently on hiatus: http://ponyscape-vectors.deviantart.com/journal/Ponyscape-Status-and-Update-369944236
Maybe it'd be nice to get some of those ponyscape features into inkscape. Like the LPEs ? The tag system sure looks useful...
On topic the tag system definitely looks like it would solve the problem for PCB design.
On 5/8/2013 10:29 PM, ~suv wrote:
On 2013-05-07 11:42 +0100, Sebastian Götte wrote:
Hi, I'm currently working on a GSoC proposal to add PCB layout and schematics editing capabilities to Inkscape (it's not as hard as it sounds). In a PCB layout, you have a number of (physically stacked) layers (one copper layer on each side of the board, possibly multiple copper layers *inside* the board, green solder mask on both sides on top of the copper layers and white print on top of the solder mask for markings etc.). I'm currently unsure on how to map these layers to SVG.
It appears obvious to map these to Inkscape layers/SVG groups. This does not work too well however, since all components on the board span multiple layers (pads for the pins on the copper layer, cut-outs for the pads on the solder mask and a package outline and part id/number on the silkscreen). If a component is moved, all parts of it (on any layers) need to be moved simultaneously, and in fact, normally it does not make sense to even select the parts of a component individually.
My problem is that this would essentially require cross-group groups, i.e. groups whose elements can be elements of other groups not part of the group, which clashes with XML's tree structure.
Currently, I have two and a half ideas on how to address this issue:
- I implement PCB layers as something different to Inkscape's layers that is just denoted by an object property (I don't like this). This attribute would be pretty similar to the z-order attribute that will be include in SVG 2.
- I find some way of "linking" multiple groups on multiple layers (I don't like this either, it's easier but more "hackish").
I'm currently leaning towards the second option since I can imagine the first will require a *lot* of work (though I will still look into that further).
Perhaps you have some ideas on how this could be implemented in pre-2.0 SVG.
Maybe worth-while a closer look (even though the fork will no longer be maintained or enhanced anymore [1]):
The 'ponyscape' fork of Inkscape implemented a tagging system in v0.4 which allows to tag objects, and a selection method based on the tag (across layers and across groups) i.e. it adds a concept of selection sets (for editing, exporting etc.). It does not treat objects with the same tag as a 'pseudo'-group though (which would for example apply an auto-transform (e.g. translate) to all objects with the same tag):
<quote> Tagging system!!
This system allows you to assign any number of tags to objects (paths, groups, etc.). If you select a tag within the dialog (ctrl-t), it will select all items which have that tag. To use the dialog, you must first create a tag using the + button. You can rename tags by double clicking on their name, and you can drag and drop tags to reorder or nest them. To assign a tag to an object, select the object and then click the + button next to the tag name in the list. To remove a tag from the list, select it under the "Items" node and press the delete key. This is especially useful for shading as you can tag all of your shading objects and in 2 clicks make them visible or hidden. (...)
</quote> <http://ponyscape-vectors.deviantart.com/journal/Ponyscape-v0-4-351369830>
Sample screenshot: http://fc04.deviantart.net/fs71/f/2013/028/7/a/4_by_flutterguy317-d5t3tuv.png
[1] project is currently on hiatus: http://ponyscape-vectors.deviantart.com/journal/Ponyscape-Status-and-Update-369944236
Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 05/08/2013 12:29 PM, ~suv wrote:
The 'ponyscape' fork of Inkscape implemented a tagging system in v0.4 which allows to tag objects, and a selection method based on the tag (across layers and across groups) i.e. it adds a concept of selection sets (for editing, exporting etc.). It does not treat objects with the same tag as a 'pseudo'-group though (which would for example apply an auto-transform (e.g. translate) to all objects with the same tag):
I'll have a look at the code. I think I'll just abuse SVG/CSS classes for that though, since that is pretty much what they were made for.
Thanks, Sebastian
participants (6)
-
Chris Mohler -
Mark Schafer -
Martin Owens -
saar drimer -
Sebastian Götte -
~suv