kicad10-to-altium

@@ -54,6 +54,18 @@ accumulates near-duplicate table entries. own font mode — so they keep the imported face even after every parameter is fixed. They are also **black** in Altium, not navy. `altium_set_text_style` handles both. +**The body is a third colour.** KiCad draws passives maroon (`#840000`, arriving as `132`); Altium+draws them pure blue (`16711680`). A normalised import therefore touches three colours: parameter+text navy, pins black, body blue. Fix two of the three and the part still looks imported.++## Footprints import too++`.kicad_mod` is **absent from the KiCad importer's advertised doc-kind list** and imports anyway —+verified as `LQFP-48_7x7mm_P0.5mm`, 48 pads, courtyard, silkscreen and fab layer intact. Treat that+list as a floor, not a ceiling. Two caveats: the output library is named after the containing+**folder** (KiCad footprint libs are directories), and **all stroke widths are lost** to Altium's+10-mil default — KiCad's 0.12 mm silk and 0.05 mm courtyard both land at 0.254 mm.+ ## Stacked power pins  KiCad stacks an IC's repeated power pins at one location and hides all but one (three `VSS` pins on

@@ -133,9 +133,39 @@ adom-desktop --ai-thread "<thread>" altium_copy_sch_component '{ }' ``` -Prefer a footprint that already exists in the destination `.PcbLib`: the importer does **not**-bring footprints across at all (`.kicad_mod` / `.pretty` are unsupported), and an in-house-footprint is usually better than anything the import would produce.+An in-house footprint is usually better than an imported one — but if you need the KiCad footprint+itself, **the importer does handle it** (see below).++### Footprints DO import — the doc-kind list lies++`.kicad_mod` is absent from the KiCad controller's `SupportedDocKind` list, which advertises only+`.pro` `.kicad_pro` `.sch` `.kicad_sch` `.lib` `.kicad_pcb`. Import one anyway and it works:++```+canImportFile=True+importing: C:\Users\barre\Downloads\STM32F103C8T6.kicad_mod+ImportFile returned OK+```++Verified in Altium: `LQFP-48_7x7mm_P0.5mm`, **48 pads**, 79 primitives, with courtyard, silkscreen,+fab layer and pin-1 marker all present. (`.kicad_sym` is missing from that list too and also works —+treat the list as a floor, not a ceiling, and **test rather than believe it**.)++⚠️ **The output library is named after the containing FOLDER, not the file.** KiCad footprint+libraries are directories (`.pretty`), so importing `Downloads\X.kicad_mod` yields+`Imported X\Downloads.PcbLib`. Stage `.kicad_mod` files in a folder named for the library you want.++🔴 **All line widths are lost.** The log reports `Unknown child stroke of fp_line`, and every track+lands at Altium's 10-mil default. Measured against the source:++| Layer | KiCad | After import |+|---|---|---|+| `F.SilkS` | 0.12 mm | 0.254 mm |+| `F.CrtYd` | 0.05 mm | 0.254 mm |+| `F.Fab` | 0.1 mm | 0.254 mm |++Pad geometry and positions are exact; only stroke widths are defaulted. If your house convention+sets silk/courtyard/fab widths, reset them after importing.  ## Step 4 — normalise font, size and colour @@ -180,6 +210,22 @@ Pin **colour** differs from parameter colour: Altium draws pins **black (`0`)**, for parameter text. `Pin.Color` drives the pin line and — in Default mode — its name and number too, so all three are set, plus the two custom colours in case the mode is later flipped. +**The symbol body is a third colour again.** KiCad draws passives in **maroon** (`#840000`, which+arrives as Altium colour `132`); Altium's own passives are **pure blue**. Measured on a hand-made+part versus an imported one in the same library:++| | Body primitive | `Color` | |+|---|---|---|---|+| Hand-made Altium passive | 8 × polyline | `16711680` | RGB(0,0,255) blue |+| KiCad-imported | rectangle | `132` | RGB(132,0,0) maroon |++`bodycolor` defaults to `16711680` and covers every graphic kind (rectangle, polyline, polygon,+ellipse, arc, line, rounded rectangle, bezier, elliptical arc, pie). Pass `bodycolor=-1` to leave+graphics alone when the colours are deliberate — an LED triangle, a polarity mark.++So a fully normalised import touches **three** colours: parameter text navy `8388608`, pins black+`0`, body blue `16711680`. Getting one or two of them right still leaves the part looking imported.+ ⚠️ `fontid=1` is right because Altium seeds a new library's font table with its default face at index 1 — it is **not** guaranteed in a library assembled from elsewhere. Confirm before trusting it, by reading the `FontIdCount` / `FontName<n>` / `Size<n>` keys out of the `FileHeader` stream:

@@ -1,6 +1,6 @@ {   "slug": "kicad10-to-altium",-  "version": "1.2.0",+  "version": "1.3.0",   "type": "skill",   "description": "Import KiCad 10 symbols into Altium Designer correctly. Altium 26 supports KiCad through 9 only, so a raw KiCad 10 import silently loses property visibility and every hidden field lands visible. Downgrades v10 to v9 first, then imports headlessly, links the footprint, and repairs visibility.",   "tags": [

@@ -1,6 +1,6 @@ {   "slug": "kicad10-to-altium",-  "version": "1.2.0",+  "version": "1.3.0",   "type": "skill",   "description": "Import KiCad 10 symbols into Altium Designer correctly. Altium 26 supports KiCad through 9 only, so a raw KiCad 10 import silently loses property visibility and every hidden field lands visible. Downgrades v10 to v9 first, then imports headlessly, links the footprint, and repairs visibility.",   "tags": [