[14]     PinConglomerate   orientation in bits 0..1 → 0/90/180/270°
[15..17] PinLength         i16
[17..19] Location.X        i16
[19..21] Location.Y        i16
[26..]   length-prefixed strings: Name, then Designator

---
name: altium-schlib
description: >
  Native Rust crate that parses Altium .SchLib (and .IntLib) binary schematic-
  symbol libraries — an OLE2 Compound File container holding a reverse-engineered
  binary pin-record format. Emits KiCad-shaped pin JSON, renders a native symbol
  SVG, and emits .kicad_sym for export. The symbol counterpart to altium-pcblib
  (footprints); together they read both halves of an Altium library natively, with
  no Altium install and no KiCad/service round-trip. Used by adom-sfconvert +
  chip-fetcher so each format renders its OWN geometry for cross-source comparison.
  Public Rust API: parse_altium_schlib_path(&Path), parse_altium_schlib_bytes(&[u8]),
  render_symbol_svg(&Value), to_kicad_sym(&Value, name).
  Validated 28/28 pins (number + name, overbars included) against KiCad 10's
  Altium importer on ADS1263IPWR.
---

# altium-schlib

Read Altium schematic-symbol libraries (`.SchLib` / `.IntLib`) in pure Rust.

## When to reach for this

- A tool needs the **pins** (numbers, names, sides, rotation) out of an Altium
  `.SchLib` without installing Altium or converting through KiCad.
- You want a **native symbol thumbnail** (SVG) that shows the Altium library's
  own geometry, for side-by-side comparison against other sources.
- You need to **export** an Altium symbol to `.kicad_sym`.

## API

| Call | Returns |
|---|---|
| `parse_altium_schlib_path(&Path)` | symbol JSON (`module_name`, `pin_count`, `pins[]`, `body`, `part_count`) |
| `parse_altium_schlib_bytes(&[u8])` | same, from raw bytes |
| `render_symbol_svg(&Value)` | standalone SVG, drawn natively |
| `to_kicad_sym(&Value, name)` | `.kicad_sym` text (export only) |

Each pin: `{ number, name, x, y, length, rotation, conglomerate }`.

## The binary pin record (the hard-won part)

Inside `/<Component>/Data`, text records are `<u16 len><u16 flags>|KEY=VAL|…`,
but **pins are binary** records whose payload starts with `0x02`:

```
[14]     PinConglomerate   orientation in bits 0..1 → 0/90/180/270°
[15..17] PinLength         i16
[17..19] Location.X        i16
[19..21] Location.Y        i16
[26..]   length-prefixed strings: Name, then Designator
```

Open the OLE2 container after padding the buffer to ≥1 MiB with `0xFF` (Altium's
FAT overshoots the real sector count, which `cfb` otherwise rejects).

## Don't re-implement this

If another Adom tool needs Altium symbols, depend on this crate — do **not**
re-walk OLE2 + re-decode the pin format. One source of truth, like
`altium-pcblib` is for footprints.

## Pairing

- Footprints → [`altium-pcblib`](https://wiki.adom.inc/skill/altium-pcblib)
- Converter that uses both → `adom-sfconvert`
- Consumer that shows the result → `chip-fetcher`