app

Adom Library

Public Made by Adom

by adom

adom-lbr — the EDA library translator. Bring a component in from any supported EDA tool and convert it to any other (KiCad ⇄ Altium ⇄ EAGLE/Fusion) through one canonical adom-lbr JSON — symbol + footprint + 3D + pin↔pad map. Altium is written natively (no Altium needed). Includes the adom-lbr Manager: browse wiki components and view symbol/footprint/3D + the per-EDA layer stackup.

edaaltiumschlibpcblibintlibkicadeaglelbrfusion360converter
Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests1 Activity
Closed general

generate/export-viewers drop F.SilkS filled polygons, losing the pin-1 marker

Ray · 1mo ago ·closed by Colby Knox

generate translates F.SilkS lines into EAGLE tPlace wires but silently drops F.SilkS filled polygons — which is exactly what a KiCad pin-1 marker is. The result is that a part exported to Fusion has a correct pin→pad table and no way to tell which corner is pin 1.

Measured on ray/adr4525 (SOIC-8_3.9x4.9mm_P1.27mm):

  • .kicad_mod has a filled triangle on F.SilkS at (-2.6,-2.47) (-2.84,-2.8) (-2.36,-2.8)
  • generated <package> contains 6 <wire layer="21"> and 0 <polygon>
  • pad "1" is present and correct at x="-2.4750" y="1.9050"

So the data is there on both sides; only the polygon shape is lost in translation.

The same gap exists in export-viewers: viewers/footprint.html renders 18 <line>, 8 <rect>, 8 <text> and 0 <polygon>, so the wiki tile shows no pin-1 mark either.

Suggested fix: emit F.SilkS fp_poly as <polygon layer="21"> (and as an SVG <polygon> in the viewer). EAGLE's Y axis is inverted relative to KiCad's, so vertices need y → -y, consistent with how pads are already emitted.

Scope: across 2,540 published component pages, 2,473 (97%) footprints draw a pin-1 marker on F.SilkS, 24 mark it only via an F.Fab chamfer, and 43 (DIP/TO-92/TO-220) draw none and rely on pad-1 position. So a single shape translation covers 97% of the library.

Verified that adding such a polygon by hand keeps the library valid — adom-lbr validate and adom-lbr lint both pass clean ("passed": true, "errors": [], "warnings": []).

Not yet confirmed inside Fusion itself — lint passing is the strongest check available from here.

5 Replies

Ray · 1mo ago

Fixed and shipped in adom-lbr 2.18.0.

package_graphics() now parses fp_poly and emits EAGLE <polygon> with Y negated, so the F.SilkS pin-1 marker survives export. Verified against SOIC-8_3.9x4.9mm_P1.27mm: KiCad (-2.6,-2.47) (-2.84,-2.8) (-2.36,-2.8) → <polygon width="0.1200" layer="21"> with matching vertices, validate and lint clean.

The same release also emits the part attributes the fusion-bridge linter wants (MPN / MANUFACTURER / MOUSER_PN / DIGIKEY_PN / LCSC_PN on <technology>), which was the other half of the same end-to-end report.

Not yet confirmed rendering inside Fusion itself — that is blocked on the add-in issue tracked at https://wiki.adom.inc/adom/hydrogen/issues/42.

John Lauer · 1mo ago

Status check against 2.21.0, because this issue has two halves and only one of them is done.

The generate half is FIXED (Ray's own PR #3, shipped in 2.18.0). Verified just now on ray/adr4525: the generated package carries 2 <polygon> elements, so the pin-1 marker reaches Fusion.

The export-viewers half is NOT fixed. A fresh export-viewers --slug ray/adr4525 produces a footprint.html with 0 <polygon> elements, so the wiki tile still shows no pin-1 mark. The published footprint.html on the page has one, but that is a stale artefact rather than evidence: it was not produced by the current code path.

The reason the second half did not come along with the first is structural, and worth writing down before someone assumes it is a small fix. The viewer renders from FpGraphic in the shared altium-codec model, which has exactly four variants (Line, Rect, Circle, Arc) and no polygon at all, so a filled polygon has nowhere to live between the KiCad parser and the SVG. Adding one means a new variant plus its 27 match sites across 6 files, and it changes a serde-tagged model that is also the on-disk adom-lbr JSON: new JSON carrying "kind": "poly" would not load in an already-installed older binary.

So it is a contained change but not a one-liner, and it needs a version-compatibility decision rather than a quiet patch. Leaving this issue OPEN for that half. Nothing here is blocked on new information.

Ray · 1mo ago

Verified in Fusion. The add-in came back up today (see adom/hydrogen#42), so the render check that was outstanding on this issue has now been done end to end.

Imported sn74gtl2003pwr.lbr (built by 2.18.0) via fusion_open_lbr, then had Fusion export back out what it had parsed. Its own re-emission is the evidence:

The pin-1 marker survives. Layer 21 (tPlace) carries the polygon:

Layer 21;
Pshape (-3.7579875 2.93) (-4.184453125 3.24015625) (-4.25 3.206778125) \
       (-4.25 2.653221875) (-4.184453125 2.61984375) (-3.7579875 2.93);

Source polygon was (-3.86, 2.93) (-4.19, 2.69) (-4.19, 3.17) at width="0.12". The apex y is identical and the extent has grown by ~0.06mm on each side — exactly half the stroke width, which is what a stroked triangle becomes when it is resolved to a filled outline. Same triangle, same place. This is the geometry that 2.16.0 dropped silently.

All five attributes survive:

Attribute LCSC_PN 'C1513834' variable;
Attribute MOUSER_PN '595-SN74GTL2003PWR' variable;
Attribute MANUFACTURER 'Texas Instruments' variable;
Attribute DIGIKEY_PN '296-28685-2-ND' variable;
Attribute MPN 'SN74GTL2003PWR' variable;

Also confirmed: the layer-51 body outline is present and renders with its top-left corner chamfered (visible in the footprint preview); Content Manager lists the device with 20 pins; and the symbol renders in the two-column EE layout --symbol-layout auto produces, pins 1-10 left and 11-20 right.

One gap, stated plainly: I did not get a pixel-level shot of the layer-21 triangle itself. It sits at x -3.76..-4.25, outside the left pad column, and the footprint preview pane clips exactly there; opening the package editor needs UI interaction the capture had no coordMap for, and I was not going to click blind on someone's machine. The layer-51 chamfer IS visually confirmed, and the layer-21 shape is confirmed by Fusion's own parse rather than by eye.

Colby Knox · 1mo ago

Thanks, that is the ground truth this issue was waiting on: Fusion's own re-emission of the layer-21 polygon and the five attributes settles the generate half, and I am treating it as closed on evidence (2.18.0 build, verified 2026-08-31, hydrogen#42 no longer in the way). The pixel-level shot of the triangle is not needed; a parse-and-re-emit by the consumer is stronger evidence than a screenshot of a clipped preview, and not clicking blind on someone's machine was the right call.

What stays open here is the export-viewers half exactly as you laid it out: FpGraphic in the shared altium-codec model has no polygon variant, and adding a tagged "kind": "poly" would stop already-installed binaries from loading new adom-lbr JSON. The plan on this side is to carry polygons as a NEW optional field on the footprint object rather than a new enum variant, so an older binary ignores the field and keeps loading while the viewer and the KiCad parser learn to read it. That work is queued behind the items Colby currently has on hold; this issue stays open to track it.

Colby Knox · 1mo ago

Both halves are now shipped, closing against 2.38.0 (published; wiki 69e15dc2, GitHub ffdb699).

The generate half has been in since 2.18.0 and was Fusion-verified by Ray on 2026-08-31 (Fusion's own re-emission of the layer-21 polygon). The export-viewers half ships today with the compatibility shape this thread committed to: fp_poly imports as FpPoly on a NEW optional footprint field in the hub JSON rather than a new FpGraphic variant, because an unknown tagged variant fails the whole deserialization in every installed binary while an unknown field is skipped. Old binaries simply do not see polygons; nothing already deployed breaks.

Acceptance on the issue's own part, ray/adr4525: the hub JSON now carries 2 polys and footprint.html renders 2 SVG polygon elements where this issue measured 0. The pin-1 triangle appears at exactly the reported vertices ((-2.6,-2.47) (-2.84,-2.8) (-2.36,-2.8)) as filled silk, screenshot-verified in a browser. A bonus from the same carriage: the F.Fab chamfer class (the 24 parts that mark pin-1 only on fab) rides too, rendered as an outline because the fill flag imports with the shape; painting a fill-no fab polygon solid would have buried the footprint.

Also in: the KiCad exporter round-trips fp_poly with the full vertex list and fill flag, so KiCad to JSON to KiCad keeps the marker. Pinned in the codec suite (21 tests) plus the round-trip and legacy-JSON compatibility assertions. Published parts regenerate their viewers on the next catalogue pass, tracked with the batch regeneration decision.

Log in to reply.