Altium SchLib Parser

What this is

altium-schlib is a native Rust crate that reads Altium Designer's binary schematic-symbol libraries — .SchLib, and the SchLib stream embedded inside .IntLib — with no Altium install and no KiCad round-trip. It is the symbol counterpart to altium-pcblib (footprints), and together they let the Adom EDA family read both halves of an Altium library natively.

It emits pins (number, name, position, rotation) and the body as KiCad-shaped JSON, renders a native SVG of the symbol, and can emit a .kicad_sym for export.

The ADS1263IPWR schematic symbol, rendered straight from its Altium .SchLib — 28 pins, both banks, correct names + numbers (validated pin-for-pin against KiCad).

Why it exists

Altium .SchLib is a Microsoft OLE2 / Compound File Binary container, and the pins inside are not the pipe-delimited ASCII records the rest of the file uses — they're a compact binary record format that no public Rust parser read. Every Adom tool that wanted Altium symbols previously had to lean on KiCad's importer (a lossy conversion that normalises everything to KiCad). This crate reverse-engineers the binary pin record so a .SchLib renders its own geometry — which is the whole point of comparing sources: you can only spot what disagrees if each format shows its own truth.

Validation

The binary decode was validated pin-for-pin against KiCad 10's Altium importer on a real part (ADS1263IPWR): 28/28 pin numbers and names match — overbars and all (C̄S̄, R̄ĒS̄ĒT̄).

Left: the symbol altium-schlib parses straight from the .SchLib. Middle/right: KiCad's own render and the datasheet extraction — every pin number and name agrees.

The format, briefly

.SchLib  =  OLE2 container
            └── /<ComponentName>/Data   ← record stream
                  ├── text records   <u16 len><u16 flags> |KEY=VAL|KEY=VAL
                  │     RECORD=1  component header (PartCount, AllPinCount…)
                  │     RECORD=14 rectangle (the symbol body)
                  │     RECORD=41 parameter
                  └── binary pin records  <u16 len><u16 flags> + payload[0]=0x02
                        [14]     PinConglomerate (orientation in bits 0..1)
                        [15..17] PinLength      (i16)
                        [17..19] Location.X     (i16)
                        [19..21] Location.Y     (i16)
                        [26..]   length-prefixed strings: Name, Designator

The OLE2 FAT that Altium writes overshoots the file's real sector count, so the crate pads the buffer with the CFBF free-sector sentinel (0xFF) before opening — the same trick altium-pcblib uses.

Public API

// Parse → symbol JSON { module_name, pin_count, pins:[…], body, part_count }
altium_schlib::parse_altium_schlib_path(&Path) -> Result<serde_json::Value>
altium_schlib::parse_altium_schlib_bytes(&[u8]) -> Result<serde_json::Value>

// Native SVG — draws the symbol directly from the parsed pins (no KiCad).
altium_schlib::render_symbol_svg(&Value) -> String

// Export path — emit a .kicad_sym (rendering uses the SVG above).
altium_schlib::to_kicad_sym(&Value, lib_name: &str) -> String

CLI

altium-schlib-json  part.SchLib            # parsed JSON
altium-schlib-svg   part.SchLib            # native symbol SVG → stdout
altium-schlib-kicad part.SchLib [name]     # .kicad_sym → stdout

Who uses it

adom-sfconvert reads Altium symbols through this crate (fully native — no service round-trip), and chip-fetcher shows the result as a per-source thumbnail next to the KiCad, EAGLE/Fusion, and datasheet symbols so you can compare what each source actually contains.

Contributing & forking — open source under the Adom org

altium-schlib is open source under the adom org on the Adom Wiki. The full source lives in this page's repo — open the Files tab, or adompkg install adom/altium-schlib and edit the package. Third-party developers are welcome to modify it and contribute back.

Modify it

• Get the source from the Files tab (or adompkg install adom/altium-schlib), make your changes, and rebuild.

Contribute back to Adom — two paths

1. Pull request (preferred). The wiki runs a PR-per-page flow: propose your change on this page and the maintainer reviews + merges it — no fork needed.

2. Fork + breadcrumb. Prefer your own fork or add-on? Publish it as your own wiki page, then drop a breadcrumb on this page pointing at your fork so it's discoverable:

   • Read existing trails: GET https://wiki.adom.inc/api/v1/pages/altium-schlib/breadcrumbs
   • Attach a breadcrumb from your fork's page targeting this anchor (a short label + your slug).

   The breadcrumb leaves a linked path back here, so Adom's AI can auto-discover your fork and surface it to users — the trail is followable both ways. Your fork stays yours; the original stays discoverable.

License

MIT — © 2026 Adom Industries Inc. Open source; see LICENSE. Modify, fork, and redistribute freely.