You'll also see the phrase "isomorphic" thrown around by JS people who like to sound fancy (myself very much included)
Hey @mcous, I had a question I'm hoping there's an answer to, using your tool is there some way I can extract all the soldermask items? Like each pad/hole, and their X/Y and size information?
I have a working prototype of this where I map the
converter.layer array through a transform function that looks up it's definition tag(if applicable) and grabs the width height and X/Y, if it's a polygon I attach the polygon to an offscreen SVG and get it's bounding box, and if it's a circle I use it's radius. It works great, however occasionally they're drawn with path objects, that may contain many pads. Example is the Arduino project (see above screenshot) any suggestions how I might go about parsing those out?
Sorry for the delay @davidworkman9! A Gerber file has three basic drawing operations:
tracespace maps those exactly from flash > use, stroke > path with stroke-width, and fill > path with fill. Unfortunately for you here, some CAD software doesn't obey the three rules above. Eagle, in this case, looks like it has output a series of strokes instead of using the more proper flash for some pads.
I don't know if it'll be particularly easy, but you could try to collect the output of
gerber-plotter itself (you'd want to attach a listener on
converter.plotter before the conversion starts; sorry that it's not easier to get to). You'd then have access to the stroke operations as data, with each "segment" as an object: https://github.com/tracespace/tracespace/blob/master/packages/gerber-plotter/API.md#stroke-and-fill-objects. That array of segments is what
gerber-to-svg uses to construct those long path data strings.
I'm a little ways into a big refactor that will output proper (or at least, almost proper) ASTs for the parse tree as well as the plot tree, which would give you fewer hoops to jump through to collect this data. Unfortunately it's going to be some time before it's in a usable state.