adom-lbr now carries symbol polyline/arc art — confirm + empty-pin-name / direct-.lbr question - Adom Symbol

Overview Files Skills Discover Packages Releases Dependencies Issues5 Breadcrumbs Pull Requests Activity

Closed general

adom-lbr now carries symbol polyline/arc art — confirm + empty-pin-name / direct-.lbr question

John Lauer · 3mo ago ·closed by John Lauer

From the adom-lbr thread (adom-lbr 2.1.1+ now carries the symbol's own drawing all the way into EAGLE/Fusion).

adom-lbr now transcribes your symbol art

It reads (polyline (pts (xy …))) and (arc (start)(mid)(end)) from the .kicad_sym and emits EAGLE layer-94 wires (symbol space is Y-up = same as EAGLE, so no Y-flip). Previously it synthesized a generic rectangle and ignored the drawing. Verified: the machine-pin symbol's 23 polylines + 1 arc now render as the real pin outline — and it shows correctly in Fusion.

Confirm: for non-rectangular parts (discretes, connectors, mechanical pins), the .kicad_sym should contain real (polyline)/(arc) body art, not just a (rectangle). The machine-pin symbol already did — just don't collapse such parts to a bare rectangle.

One thing to check on your side

KiCad pins with (number "1") (name "") (empty name — common on 1-pin mechanical parts) previously produced <pin name=""> + <connect pin="">, which Fusion rejects ("has errors and cannot be opened"). adom-lbr 2.2.1 now falls back to the pad number when the name is empty, so it's handled downstream — but if adom-symbol emits .lbr directly (the Fusion path), it needs the same fallback, and the same round-pad/silk fixes. Question: when adom-symbol writes .lbr itself, does it call adom-lbr (now fixed) or write its own? If its own, it carries the same 3 bugs.

1 Reply

John Lauer · 1mo ago

Answer from the code: adom-symbol does not write EAGLE XML itself. The Fusion/Altium/OrCAD delivery path in src/deliver.rs shells out to adom-lbr generate --sym <file>.kicad_sym --output <file>.lbr and then sends that .lbr through Adom Desktop (send_files + fusion_open_lbr). So the empty-pin-name fallback, the round-pad fix, and the silk fix in adom-lbr 2.2.1+ all apply to symbols delivered from adom-symbol automatically; there is no second .lbr writer carrying the same bugs.

On the polyline/arc confirmation: discretes (category: "discrete") start from the KiCad standard-library baseline and keep its real (polyline)/(arc) body art, plus a baked thin-polyline 3D-chip icon. Only Category A ICs get a plain (rectangle) body, and for those the chip outline goes to adom-lbr through the outline contract (<stem>-outline.mm.svg + .json, adom-lbr generate --symbol-art). As of adom-symbol 1.1.9 that contract is also written when render --iso is given a raster PNG (it uses the sibling <mpn>-3d-outline-*-named.svg).

Closing as answered.