Integration in LibrePCB, questions about pcbdata format

[ubruhin]

Hi,

First of all, thanks for this awesome project! I'm the author of LibrePCB and I'd like to integrate this BOM tool into LibrePCB. The plan is to re-implement the HTML generation logic in Rust (possibly published as an independent Rust crate, not sure yet) and integrate it in LibrePCB. From license perspective this should be fine I guess, HTML/CSS/JS files would keep the MIT license and of course I'd keep the "Created using InteractiveHtmlBom" statement in the menu. Let me know if you have any concerns about this.

Now, regarding implementation a few questions came up:

1. Is there any reason to use font_data? I guess I could just include stroke texts as plain polygon geometries, or does this bring any drawbacks?
2. What is the purpose of the footprint/center attribute? I do not see any effect of it, even if I omit it completely. It seems the footprint/bbox/pos is used for placement.
3. Same question for footprint/ref, it does not seem to have any effect?

But to be honest, I'm mostly confused about the overall data structure of footprints and bom. Why isn't the footprint/ref actually used, and omitted in bom? Example:

pcbdata = {
  "footprints": [
    {"ref": "R1"},
    {"ref": "R2"},
    {"ref": "R3"}
  ],
  "bom": {
    "both": [
      [0, 1],
      [2]
    ]
  }
}

IMHO this would make more sense, as every footprint occurs only once in the image, so every reference designator should be in pcbdata only once too.

Also the bom/fields attribute seems a bit strange. Couldn't it be part of the corresponding BOM rows? Example:

pcbdata = {
  "bom": {
    "both": [
      {
        "footprints": [0, 1],
        "fields": ["100R", "0603"]
      },
      {
        "footprints": [2],
        "fields": ["1k", "0603"]
      }
    ]
  }
}

...just my thoughs. Maybe this structure is simply chosen for easier processing by JS?

[qu1ck]

Hello,

Of course you are free to use this code as MIT license permits pretty much anything. Even leaving a link is not required, although appreciated.

Regarding data format, it's not perfect as it evolved organically together with kicad and ibom features. Some things are deprecated or only relevant for old kicad formats. More specifically:

Is there any reason to use font_data

This is for kicad v4 - v5.1. Rendering logic of those glyphs in javascript is also ported from kicad code and has specific logic for escaping etc which is not applicable for other EDAs. Just use svgpath or polygons.

What is the purpose of the footprint/center attribute?

It's deprecated (I should mark it as such), it was used before the rotated bounding box for footprints was introduced.

Same question for footprint/ref

This was also used before internal footprint enumeration was introduced because refs are not really unique. But I'm not 100% sure it's completely unused, please check filtering and sorting logic.

Why isn't the footprint/ref actually used, and omitted in bom?

I used ref until these use cases popped up which proved that refs can not be relied to be unique:

1. In house panelized boards where one board is really N copies of a smaller board with multiple copies of each footprint
2. Multipart connectors which are separate footprints on the board for convenience but are really single unit

Because of this footprints are referred to by their index in the array instead of references. Bom consists of (ref, id) tuple for convenience, just id would have been enough but would need more lookups or preprocessing in js.

Also the bom/fields attribute seems a bit strange. Couldn't it be part of the corresponding BOM rows?

No, because bom row does not necessarily have same values for all components. When bom is grouped by a subset of shown fields then if a row has components with different field values, that cell shows comma separated list of all distinct values.

Semantically fields could also be part of footprint struct but I just made a division of what info is needed to draw the part and what is needed to render the bom table, first went into footprint, second into bom struct.

Hope this helps.

[ubruhin]

Thanks a lot for the detailed clarifications @qu1ck! That really helps.

Best regards

[ubruhin]

Just for your information, integration into LibrePCB is ready! 😃

Implemented as a generic Rust library with a custom C++ wrapper, see details in LibrePCB/LibrePCB#1485.

[qu1ck]

Nice work!