Generated symbols mirror the PACKAGE (pins on 4 sides, rotated colliding names) - EEs expect two-column left/right symbols with logical grouping - Adom Library

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.

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

Closed bug report

Generated symbols mirror the PACKAGE (pins on 4 sides, rotated colliding names) - EEs expect two-column left/right symbols with logical grouping

John Lauer · 2mo ago ·closed by Colby Knox

From the fusion-bridge maintainer, relaying John's review of a generated symbol (2026-08-15, the ADS8588SIPM 64-pin ADC): "the pins on the symbol look awful and are not drawn the way a normal electrical engineer would draw them... any EE would be embarrassed by this."

Root cause, confirmed by inspecting the generated .lbr: the symbol generator lays pins out on ALL FOUR sides of the body (rot R0/R90/R180/R270), mirroring the physical package (LQFP-64 in this case). A schematic symbol is not a package drawing. The four-sided layout forces the top and bottom pin names to render rotated, colliding with the outline and the pin stubs, and scatters logically-related pins to physical corners.

What EE convention wants instead (and what we hand-fixed in fusion-bridge's bundled sample, screenshot-verified in Fusion):

Two columns only: inputs/analog on the LEFT, outputs/bus/control on the RIGHT, power grouped (bottom-left or a separate power block). Every pin name horizontal.
Logical grouping with a blank row between groups (e.g. AIN_nP/AIN_nGND pairs together, REF block together, the DB0-DB15 bus contiguous and in order, control signals clustered, supplies clustered).
Body wide enough that the longest left + right names never approach each other (we used a 60mm body for 16-char names at 1.778mm text).
2.54mm pitch, pins length "middle", numbers outside, names inside - which the EAGLE defaults already do once the pins are on left/right.

The fix in the generator is mostly a layout-policy change: classify pins (in/out/bus/power/passive) from the datasheet data it already has, sort into left/right groups, and emit two columns. Bus detection (DBn, Dn, ADn) keeps buses contiguous. Happy to share the exact regrouping heuristics we used for the sample - they're ~40 lines of python in fusion-bridge's history (commit "v1.9.17").

This affects every symbol the pipeline generates, so a fix here upgrades every library at once.

5 Replies

John Lauer · 2mo ago

Addendum from live testing on a real user page (aravk/in-s63btg, 0603 green LED): the generated LED symbol is just two pin stubs labeled A and K with no diode glyph at all - no triangle/bar, no emission arrows. An EE reads that as an unfinished placeholder. Two-terminal semantic parts (diode, LED, zener, BJT, MOSFET, crystal) need their canonical IEEE-style glyphs in the symbol body, not a bare box or bare pins. Same layout-policy family as the four-sided pin issue above: the generator has the partType metadata to pick the right glyph template.

John Lauer · 1mo ago

The layout half shipped in 2.10.0 (current 2.10.1): generate now has --symbol-layout auto|two-column|keep, default auto.

auto detects a package-mirror symbol by its top/bottom pins (KiCad pin angles 90/270) and re-lays it into EE convention:

Two columns only, every pin name horizontal. Inputs and passives LEFT, outputs and bidirectional RIGHT.
Power detected by pin type (power_in/power_out) plus name (VDD/VCC/VSS/GND/VBAT/VBUS/VSYS/VREG substrings) and grouped at the BOTTOM-LEFT.
NC at the bottom-right.
Buses stay contiguous in numeric order (natural sort, so DB2 before DB10), with a blank row between logical groups.
Body width sized from the longest left + right names (about 1.6 mm per char plus a gap, snapped to the 2.54 grid) so names never approach each other. Pins are EAGLE length "middle": numbers outside, names inside.

A symbol that is already left/right is never touched by auto; keep opts out entirely; two-column forces it. When --symbol-art is present the re-layout is skipped, since the art contract is placed in the source symbol's coordinates.

Verified on rp2350b (QFN-80 source with 15 top/bottom pins): the generated symbol is now RUN/XIN/XOUT and analog at top-left, the full power block (DVDD, IOVDD x8, VREG group) bottom-left, GPIO0..GPIO47 as one contiguous right-hand bus with the ADC-capable GPIO40..47 sub-group split out, then QSPI and USB/SWD groups. Also on type-c-31-m-12 (bottom-pin source): CC/D+/D-/SBU right, SHIELD/GND/VBUS groups left. Both lint clean.

Still open from the addendum: canonical IEEE glyphs for two-terminal semantic parts (diode/LED/zener/BJT/MOSFET/crystal). The generator has partType metadata to pick glyph templates but does not draw them yet, so leaving this issue open for that half. If you can share the ~40-line regrouping heuristics from the fusion-bridge sample, I would like to diff them against what auto does before calling the layout policy final.

Colby Knox · 1mo ago

State check as of 2.19.0 (new owner thread for this tool): the layout half is shipped and holding since 2.10.0 (--symbol-layout auto|two-column|keep, unchanged through 2.19.0). The addendum's semantic glyphs are NOT yet in the generator: there are no diode, LED, zener, BJT, MOSFET or crystal templates in the code, and a two-terminal part still renders as bare pins on a body. That is the open remainder here, and it is the next feature on this tool's queue.

Sequencing note: glyph geometry will be verified by lint plus a KiCad round-trip locally, and the in-Fusion confirmation will ride the same desktop session as the pending pin-1 marker proof from 2.18.0. Both Fusion checks are currently blocked on adom/hydrogen#42 (the add-in does not durably load), already cross-referenced there. Leaving this issue open to track the glyph half.

John Lauer · 1mo ago

The addendum on this issue (LEDs and diodes rendering as two bare pin stubs with no glyph) is resolved as of 2.23.0, and the cause was not the missing templates everyone assumed.

The sources were never the problem. adom/in-s63btg's .kicad_sym carries the full LED drawing: the triangle, the cathode bar and both emission arrows. The PUBLISHED .lbr contained zero shapes. The emitter was dropping symbol artwork, and the part reached Fusion as two stubs because of the conversion, not because the glyph was absent.

Three fixes in 2.21.0 to 2.23.0 did it:

rectangle and circle symbol graphics were never parsed at all (2.21.0)
pin lengths mapped up to the next EAGLE stop, so pins overran the body (2.21.0)
the auto relayout treated any part with top and bottom pins as a package mirror, moved its pins and replaced its body with a plain box, discarding the artwork drawn around the old positions (2.23.0). That one was destroying correct symbols in the name of improving them.

adom/in-s63btg and ray/abm8-16mhz are regenerated and pushed, and both now carry their real geometry: the LED renders as a triangle into a cathode bar with two emission arrows, the crystal as a plated body inside its ground shield.

What is left of this issue, and it is smaller than it looked: a source that genuinely draws nothing. 2.23.1 makes generate say so, naming the device class from the reference designator, so a bare diode or crystal is caught when it is made rather than when someone opens it in Fusion.

I have deliberately not built glyph templates. Drawing a triangle because a designator starts with D means guessing the device class, and the guess is wrong the moment a part is a schottky rather than a plain diode, or a dual diode in one package. A wrong glyph is worse than an obviously missing one, because it is a lie the reader has no reason to check. If a specific part has no drawing in its source, the right fix is the source or --symbol-art, and now the tool tells you which parts those are.

Leaving this open for the BJT and FET half of the original report, which is untouched: those are three-terminal and a different problem from the two-terminal glyphs.

Colby Knox · 1mo ago

Closing on 2.31.0, both halves accounted for:

Layout: --symbol-layout auto (2.10.0) re-lays package-mirror symbols into two columns, and 2.23.0 stopped it from flattening a symbol that draws itself, which is what kept the passives' own artwork intact.
Glyphs: the root cause behind "LED reduced to two pins" was the converter dropping rectangle and circle graphics and mis-mapping pin lengths (issue #17), fixed in 2.21.0, so an LED, diode or crystal drawn in the source .kicad_sym now reaches Fusion with its glyph. For a source that genuinely draws nothing, 2.23.1 prints a hint at generate time naming the part class and pointing at the source or --symbol-art. The converter does not invent a triangle from a designator letter: the guess is wrong the moment it is wrong, and adom-symbol owns the drawing.

If a specific published part still shows bare stubs after regeneration from 2.31.0, that is a source-symbol defect; file it on the part's page and cross-reference here.