As discussed in #104 using WebGL in the view app could improve zoom performance as well as allow for a 3D rendering of boards.

Three.js is probably the most widely used lib for WebGL. There is also a Three.js SVG Loader
and a React renderer for Three.js.

Can't figure out what's going on with this .drd file made by @sangavalerian and @rwb27 using Eagle I believe.

https://github.com/rwb27/openflexure_nano_motor_controller/blob/18a06fb9a9e6a0a873b6234e204a5500d0b735d9/sangaboard_v0.2/sangaBoard-v0.2%20gerber/sangaboard_v02.drd

It renders much bigger than expected with both gerber-to-svg and gerbv. gerber-to-svg warns:

warning at line 15 - zero suppression missing; detected leading suppression
warning at line 13 - notation not set; using backup notation: A

I tried to add all the possible combinations of --units and --zero but nothing seems to make it better (only worse). Is this actually just plotted much bigger than expected for some reason?

I am struggling a bit with moving from 0.0.4 to 0.1.0 in monostable/kitnic. The last API was quite low level, and this one is too so there are lots of details to work out.

It would be nice if pcb-stackup had a higher level API and I was thinking about implementing it. This steals ideas from gerber-to-svg and provides a stream but also a callback API. pcbStackup would use whats-that-gerber if no layerType is provided but the user could also specify a layerType themselves. Using gerberToSvg would not be needed.

I have outlined what I am thinking so far in (pseudo) Typescript below just so we can easier talk about the types. I would still write it in ES5. The ? indicates an optional type that can remain undefined.

function pcbStackup (files : File[],  options? | callback?, callback?) : StackupStream;

interface File {
    data       : string | Buffer | stream.Readable;
    filename   : string;
    layerType? : string;
}

function callback (error : string, stackup : Stackup) : void;

interface Stackup {
    top    : string;
    bottom : string;
}

interface StackupStream {
    top    : stream.Readable;
    bottom : stream.Readable;
}

What do you think?

Hi,

I noticed PCB Stackup will intermittently output an invalid SVG. Depending on the browser/SVG viewer, it will display either as a black or blank image.

It appears to be caused by shortId.generate() occasionally returning a string which starts with a numeric character. For example "0C3Vwf2nt".

XML IDs aren't allowed to start with a numeric character, causing the SVG viewer to misbehave.

The outline of 8BitMixtape/NextLevelEdition is not being rendered properly as noticed in kitspace/kitspace#81.

I had a bit of a play in kitnic/NextLevelEdition (see also the re-plot branch which gives even worse results) but didn't get anywhere.

I have added this as a test-case in the add-8bit-mixtape branch with a similar looking result.

Unfortunately I can't share the gerber files (or final renders) in public.

It's a square panel with 4 round PCBs and 4 small square PCBs, routed around the edges and connected with mousebites. Mousebites are pretty common for us.

An example of the outline from the tracespace viewer:

We're trying to use pcb-stackup to create a top and bottom view.

• maskWithOutline == false, blue in the screenshot becomes black, instead of the soldermask.
• maskWithOutline == true, it cuts out the PCBs completely.

The next part might be a separate issue.

The border of the PCBs has a gold finish (along with the pads, etc.) but for some reason the border isn't covering the entire circle on the 2nd and 4th PCB in the panel. It's covering 90-360 degrees of the PCB, the first 90 degrees isn't there.

I can replicate this on the viewer. I can send the files via e-mail and I'm happy to provide more feedback if needed.

Please see contents of files.zip attached.

output.svg was rendered by pcb-stackup.

expected.pdf was rendered automatically by the quotation tool at eurocircuits.com

The output from pcb-stackup is always a solid filled rectangle and never represents the correct outline of the PCB for any of my Gerber files (I have tried several).

These Gerber files were output by OrCAD.

The same Gerber files were provided to the online tool at eurocircuits.com which renders the PCB correctly so there seems to be enough data in the files.

I have also included the application code (using pcb-stackup) that generated the output.svg file.

Attached:
files.zip

Hellow @mcous you probably remeber me I opened a issue on gerber-parser week ago. It smees like the outline doesn't apply :(
All my gerber files are with some deprecated futures of the current standart so at first I though that the outline is missing cuz of that but than I used the files from svgerber and the result is the same ...

This is the script that I use to generate the top and bottom files (I's almost copy-paste from the one from README but still ... )

var fs = require('fs')
var gerberToSvg = require('gerber-to-svg')
var pcbStackup = require('pcb-stackup')
var idLayer = require('pcb-stackup/lib/layer-types').identify
var walk = require('walk')
var path = require('path')
var walker = walk.walk(path.join(__dirname, 'samples'))
var gerberPaths = []
var layers = []
var files = []

walker.on('file', add)
walker.on('end', pcb)

function add(r, f, n) {
    var i = r + '/' + f.name
    files.push(i)
    n()
}

function pcb() {

    files.forEach(parse)

    function parse(filename) {
        var gerberString = fs.readFileSync(filename, 'utf-8')
        var layerType = idLayer(filename)
        var options = {
            object: true,
            drill: (layerType === 'drl')
        }
        var svgObj = gerberToSvg(gerberString, options)
        var p = {
            type: layerType,
            svg: svgObj
        }
        layers.push(p)
    }

    var stackup = pcbStackup(layers, 'mb')
    var top = __dirname + '/top.svg'
    var bot = __dirname + '/bottom.svg'
    var topP = gerberToSvg(stackup.top)
    var botP = gerberToSvg(stackup.bottom)

    fs.unlinkSync(top)
    fs.unlinkSync(bot)
    fs.writeFileSync(top, topP)
    fs.writeFileSync(bot, botP)
}

Hi and thanks for this excellent library.

I've managed to generate SVGs from my gerber files.
Do you by any chance have a nice css example to use?

I'm trying to build a forum plugin (forum.mysensors.org) so the community users will get auto-generated svg from their gerber files in forum posts.

If WebGL/threejs works as expected. I hope to create a 3D viewer from the SVGs.

Should we make a gitter.im chat for this repo so I can complain about the CI builds? 😈

In all seriousness, seems like it's got a bit of attention so people might need some help that can easier be handled in chat, and we can have quicker back and forth if we happen to be working at the same time.

Seems like our most popular option 😄

This ticket taking over for mcous/gerber-plotter#5

The plotter deals with arc and arc validation inconsistently and has more room to play than it gives itself according to the Gerber spec.

expected behavior

If given an arc instruction, the plotter should plot a valid arc, where a "valid arc" is:

Any continuous and monotonic curve starting at the start point and ending at the end point, approximating the ring with the given center point and with inner and outer radii equal to the start radius and end radius is a valid rendering of the arc command

actual behavior

The plotter's arc calculations, especially in single-quadrant mode (G74) can and will give up on certain arcs and purposefully plot nothing at all. This leads to really unexpected renders, especially downstream in pcb-stackup-core, because arcs can occur often in outline files

As soon as whats-that-gerber 3.0.0 is released we should update it in pcb-stackup too.

Reference: tracespace/whats-that-gerber#20

So we can flesh out some ideas.

Names?

• gerber2pcb,
• gerberup
• stackup
• pcb-stackup

We definitely want to take in shell expansion:

$ stackup gerbers/*

Easy to specify soldermask color with the rest adapting (similar to how kitnic.yaml color is handled) would be nice:

stackup --color red gerbers/*

Let's keep adding our thoughts here.

Thank you for your very quick fix to the gerber-to-svg project. I have since discovered this pcb-stackup project and tried running the same files through using the sample code from the README and changing gerberPaths to point to my gerber files.

The output I get is:

node_modules/pcb-stackup/lib/sort-layers.js:9
var side = type[0]
               ^

TypeError: Cannot read property '0' of undefined

Since this is a different project, I have attached the same Gerber files here as an example.
KB0006R00.zip

Try and figure out why Inkscape doesn't display the SVGs.

8bit-mixtape:

It's getting quite annoying, even when I can get it to pass I normally have to restart the build a few times.

Currently pressing restart on https://travis-ci.org/tracespace/pcb-stackup/jobs/147398037

I am using the test-fm-transmitter branch to figure out what is going on with this. I added zero:'L' to the options like you suggested but it's still not working.

In #13 we were talking about options: --color-fr4, --color-cu, --color-ss which should have JS equivalents. Having something for type of finish (HASL, ENIG etc instead of colours) would probably be nice. Maybe I should also pull in the styles from Kitspace?

Mainly creating this so we don't have to hunt for it in the gitter chat later.

For React this interface function below will work. Should we provide this in pcb-stackup?
Or maybe lower down in gerber-to-svg? The lack of unique key properties on some tags is also an issue.

var React = require('react')
var camelCase = require('lodash.camelcase')

function createElement(type, props, children) {
  Object.keys(props).forEach(key => {
    var newKey

    if (key === 'xmlns:xlink') {
      newKey = 'xmlnsXlink'
    }
    else if (key === 'xlink:href') {
      newKey = 'xlinkHref'
    }
    else if (key === 'class') {
      newKey = 'className'
    }
    else if (/-/.test(key)) {
      newKey = camelCase(key)
    }
    if (newKey && newKey !== key) {
      props[newKey] = props[key]
      delete props[key]
    }
  })

  return React.createElement(type, props, children)
}

Issue pulled from mcous/svgerber#18 by @kasbah.

Builder should scale (with a transform) layers that are different than the "base" layer. Base layer should probably be the outline layer if it exists, but could fall back to the copper layer.

.drd can be used as drill files from Eagle. Right now, identifyLayer says they are Gerber outline files. According to the tests, this is because OrCad uses that extension for outline files, but seeing as Eagle is more popular and I don't have any evidence that OrCad actually does this, .drd should be switched to drill.

If not, do you need hosting or something?

I converted a gerber file to svg and open it with Inkscape editor. In Inkscape, some "mask"s disappeared. The wrong image is here.

Inkscape (wrong)	Chrome (good)

Finally I found that inserting a "<g>" tag between "<mask>" tag and its children can fix this problem. I changed the 30th line of "packages/gerber-to-svg/lib/_utils.js":

  //return element('mask', attributes, children) 
  return element('mask', attributes, [element('g', {}, children)])

Hope my code will help you.

This ticket is taking over for tracespace/gerber-to-svg#36. See that ticket for some background.

I believe overuse of <use> is making our SVG output harder for browsers / image editors to deal with. For some things (e.g. referencing entire layers multiple times in pcb-stackup) <use> is the best solution for the job. For other things (e.g. individual pad flashes in a single layer) a <use> could be easily replaced in most instances with a single <path>.

Problems:

• Rendering nested <use>s is slow (anecdotal)
• Firefox (still!) has positioning problems with <use>
  • https://codepen.io/mcous/pen/FfxkC
  • https://bugzilla.mozilla.org/show_bug.cgi?id=844258
• Willing to bet that they make Inkscape unhappy in some way

This change should result in simpler SVG output and could even reduce the output file size (each <use> needs a corresponding shape in <defs> with a unique ID.

<use> tags in gerber-to-svg have some nice side-effects with regards to identifying which Gerber "tool" created a given shape by inspecting the id, but that sort of metadata could (and probably should) be attached to a data-attribute rather than inferred from an internal id.

So you don't have to re-process all of them when you are just looking at a single case. It would require front-end changes only as the back-end already handles each case individually.

hi thanks for amazing project ,

i want to know can we do mirroring in this gerber2svg package
if yes how ? is i search for mirror but have not found anything in repo

thanks

Was raised in kitspace/kitspace#140 and tried it out myself. If you press "Generate CAM Data" by default it will create a zip with:

outputs/profile.gbr
outputs/gerber_job.gbrjob
outputs/drills.xln
outputs/soldermask_top.gbr
outputs/silkscreen_top.gbr
outputs/soldermask_bottom.gbr
outputs/copper_bottom.gbr
outputs/solderpaste_bottom.gbr
outputs/solderpaste_top.gbr
outputs/copper_top.gbr
outputs/silkscreen_bottom.gbr

We should add these to whats-that-gerber.

Bit of trouble with @GaudiLabs gerbers which seem to have disappeared, though gerblook deals with the outline ok (but has some issue with the mask).

With createElement now being an option in gerber-to-svg should we add an option to pass in a custom function in from here?

The usecase I am thinking of is creating badges for kitnic.it where I would like to add background and text to the rendered SVGs. I guess what I really need is an object instead of string return and and then use xml-element-string after I have modified it. But I guess this is the same as having the createElement be the identity function.

(@mcous has taken over this post to elevate comment below):

New package proposal: @tracespace/stats. It think it could have the same signature as pcb-stackup or be included in pcb-stackup by default.

As a user rendering boards, I often to collect other information about the board for manufacturing / quoting purposes. The following pieces of information should be "easy" to collect:

• Number of layers of a given type
• Minimum trace width
• Number of drill hits
• Drill sizes
• Board size
• Number of pads
  • At the moment, hard to distinguish between TH and SM pads

Both @kasbah and myself have received emails about this sort of functionality. Also see #139

Was just looking at index.js#L76. If we used the same name as core here it would just be:

stackup.layers = stackupLayers

Since we now have a converter property in the cache users could pass it directly to core if they wanted to.

Alternatively we could rename the property to layerType in core.

Sometimes, the parsed type of a file (gerber or drill) may differ from the whats-that-gerber inferred type. In the case of a parsed drill file, I think we should consider always setting the type as drl regardless of what the filename suggests.

In the other direction, technically gerber files may be used as drill files (not that I've ever seen it) so we may not be able to do anything there.

According to the Altium documentation internal planes can have an extension of GP[0-9]. I would personally match them in the icu layer and change the regex of (g) to (gp?).

Code ref: index.js#L80
Issue ref: tracespace/whats-that-gerber#23

This is what I did for svgerber#23. Our test case for that was this MCHCK board, rendered using pcb-stackup below (with corners not cut off properly).

I know that I need to modify src/board-shape/index.coffee#L13 and change a few tests as well so I wanted to ask if you think it is the right solution.

As an aside, the tests seem to rely on the input paths array mutating although this functionality isn't in actual use (is that right -- seems a bit odd)?

Offending line:

Should read something more along the lines of:

var viewboxLayers =
    useOutline && outline && outline.converter.width && outline.converter.height
      ? [outline]
      : allLayers

gerbv seems to not support some instructions related to the (newer) GerberX2 format. Is this the case with tracespace?

As discussed on svgerber#20. A good example are the Bus Pirate v3.6 gerbers (rendered by pcb-stackup below).

Svgerber would render this like so, with the outline not working properly. Not sure why it's different, maybe there is another issue.

Let me know if you still think repairing small gaps is the right approach anyway.

The other day we received Altium files that included a .gm15-extension. At the moment it only matches single digits with (gm[l\d]$. Changing this to (gm[l\d]{1,2}$ solves it for us. Do you think there would be any reason not to match two digits in this case?

I can of course send a PR for this.

Code ref: index.js#L87

Drill hits are missing from current image; the drill file uses unspecified leading zero suppression.

Can't quite figure out why the drills aren't working properly with this one.

Output: https://github.com/kasbah/pcb-stackup-test/blob/master/output/FM_Transmitter-top.svg

The plots of these three Altium projects seems to be making it impossible for me to convert the SVGs to PNG.

I already filed with svg2png as they cause it to crash and it's reported further upstream with PhantomJS. A PhantomJS downgrade makes for some crappy PNGs of these three projects.

When using PCB-stackup, I randomly get boards that show up completely black. I dug into it and it looks to be because the random hash class names start with a number, which is an invalid CSS selector. I was going to make a PR, but I wasn't sure how the IDs get generated.

Here's an example:

<svg id="4hlxy2YLb_top" version="1.1" xmlns:xlink="http://www.w3.org/1999/xlink" stroke-linecap="round" stroke-linejoin="round" stroke-width="0" fill-rule="evenodd" clip-rule="evenodd" width="335.2mm" height="55.8mm" xmlns="http://www.w3.org/2000/svg" xmlns:ev="http://www.w3.org/2001/xml-events" style="overflow: hidden; width: 100%; height: 500px;">
   <defs>
      <style>.4hlxy2YLb_fr4 {color: #666;}
         .4hlxy2YLb_cu {color: #ccc;}
         .4hlxy2YLb_cf {color: #c93;}
         .4hlxy2YLb_sm {color: #004200BF; opacity: 0.75;}
         .4hlxy2YLb_ss {color: #fff;}
         .4hlxy2YLb_sp {color: #999;}
         .4hlxy2YLb_out {color: #000;}
      </style>
   </defs>
   <g transform="translate(0,50800) scale(1,-1)">
      <g mask="url(#4hlxy2YLb_top_mech-mask)" clip-path="url(#4hlxy2YLb_top_out)">
         <g mask="url(#4hlxy2YLb_top_sm-mask)">
            <rect x="-2500" y="-2500" width="335200" height="55800" fill="currentColor" class="4hlxy2YLb_sm"></rect>
         </g>
      </g>
   </g>
</svg>

Given a set of files, if the first identified file of that layerType fails to parse it would be good to fall back to another file with the same layerType.

Taking over for tracespace/gerber-to-svg#38

A bug with how gerber-to-svg handles step-repeats is causing issues downstream in pcb-stackup-core

expected behavior

A step-repeat disable line (%SRX1Y1I0.0J0.0*%) appearing without any preceding step-repeat should not affect the SVG output.

actual behavior

Upon encountering the SR disable, gerber-to-svg creates a wrapping group, throws it in the defs, and <use>s it in the render group. This unnecessarily increases the complexity of the SVG file and messes up outline masks if the layer is a board outline (see #48).

I am trying to switch over from my hacked together svgerber-board-builder but having some issues parsing the same gerber files.

Here is a test I put together comparing stackup to builder. You can run the it with npm run stackup and npm run builder. Running stackup will give you "end of file encountered before required M02 command" errors while builder will silently succeed.

Rather than the dimensions used in the Gerber files. The outlineGapFill option should also be in mm by default.

This ticket is taking over for mcous/gerber-plotter#14.

Although it should be exceedingly rare (as in, I've only seen it happen as a result of other bugs in the stack), the plotter crashes hard if it attempts to operate using a tool that isn't defined.

expected behavior

If the plotter encounters an operation using a tool that isn't defined, it should emit an error and no-op.

actual behavior

The plotter throws a TypeError that isn't catchable because it's happening in an async handler.

We're using pcb-stackup in a browser. Every so often we have a PCB that locks up the session and never hands it back. I can't share the gerber files but a mechanism to handle such situations would be great.