Altium

Introduction

Altium Designer is a commercial PCB design tool that uses a family of proprietary binary file formats. All primary design files (.SchDoc, .PcbDoc, .SchLib, .PcbLib) are stored as Microsoft OLE Compound File Binary Format (CFB) containers. Each container holds a tree of named storage directories and data streams.

KiCad imports designs from several Altium-family products:

Product PCB Extension Schematic

Altium Designer

.PcbDoc

.SchDoc

Circuit Studio

.CSPcbDoc

 — 

Circuit Maker

.CMPcbDoc

 — 

Solidworks PCB

.SWPcbDoc

 — 

Circuit Studio, Circuit Maker, and Solidworks PCB use the same PCB binary format as Altium Designer. Schematic import is only available for Altium Designer files.

Additional file types:

  • .PrjPcb — Project file (INI-style text)

  • .SchLib — Schematic symbol library (CFB container)

  • .PcbLib — Footprint library (CFB container)

  • .IntLib — Integrated library (CFB container wrapping compressed .SchLib and .PcbLib streams)

OLE Compound File Structure

All binary Altium files use the Microsoft Compound File Binary Format (also known as OLE Structured Storage, specified in MS-CFB). The file begins with the standard CFB signature:

D0 CF 11 E0 A1 B1 1A E1

The CFB container organizes data as a hierarchical filesystem of named storages (directories) and streams (files). KiCad uses the compoundfilereader library to navigate this structure.

The ASCII schematic variant is not a CFB file. It begins with a |HEADER= text prefix and stores records as pipe-delimited key-value properties. Both binary and ASCII schematics are supported.

Coordinate System and Units

Altium stores coordinates as 32-bit signed integers in units of 1/10000 mil (where 1 mil = 0.001 inch). The conversion factor is:

kicad_nm = altium_unit * 2.54

The ALTIUM_PROPS_UTILS::ConvertToKicadUnit() function performs this conversion. Text-format properties store coordinates in mil strings (e.g., "100mil") while binary records store raw integer values.

Altium uses a standard Cartesian coordinate system with Y increasing upward. KiCad inverts the Y axis, so all Y coordinates are negated during import.

Schematic coordinates split each value across two property keys: a base value in mils (e.g., LOCATION.X) and a fractional component in 1/10000 mils (e.g., LOCATION.X_FRAC).

Schematic Format (.SchDoc)

Altium schematic files exist in two variants: a binary CFB container and an ASCII text format.

Binary Container Structure

The CFB container for a .SchDoc file contains these streams:

Stream Name Contents

FileHeader

Primary record stream containing all schematic objects as property-map records

Storage

Embedded binary file storage (images, fonts) as sequential binary records

Additional

Additional embedded data in the same format as Storage

The importer processes these streams in order: Storage first (to cache embedded files), then FileHeader (to parse all schematic objects), then Additional (to load supplementary data).

ASCII Variant

The ASCII format begins with the prefix |HEADER= followed by pipe-delimited key-value records. Each record is terminated by a newline. The parser converts both formats into the same property map representation before interpretation.

Record Types

Each record in the FileHeader stream is identified by a RECORD property containing an integer type identifier. The complete enumeration:

ID Name Description

0

HEADER

File header and version information

1

COMPONENT

Symbol instance (component placement)

2

PIN

Component pin

3

IEEE_SYMBOL

IEEE standard symbol (not imported)

4

LABEL

Text label

5

BEZIER

Bezier curve

6

POLYLINE

Polyline

7

POLYGON

Filled polygon

8

ELLIPSE

Ellipse

9

PIECHART

Pie chart arc (filled)

10

ROUND_RECTANGLE

Rounded rectangle

11

ELLIPTICAL_ARC

Elliptical arc

12

ARC

Circular arc

13

LINE

Line segment

14

RECTANGLE

Rectangle

15

SHEET_SYMBOL

Hierarchical sheet symbol

16

SHEET_ENTRY

Sheet symbol port

17

POWER_PORT

Power port symbol

18

PORT

Port (inter-sheet connector)

22

NO_ERC

No-ERC marker

25

NET_LABEL

Net label

26

BUS

Bus line

27

WIRE

Wire

28

TEXT_FRAME

Text frame (box with text)

29

JUNCTION

Junction dot

30

IMAGE

Embedded image

31

SHEET

Sheet properties (size, fonts, title block)

32

SHEET_NAME

Sheet name text

33

FILE_NAME

File name text

34

DESIGNATOR

Component designator text

37

BUS_ENTRY

Bus entry

39

TEMPLATE

Drawing template reference

41

PARAMETER

Component or sheet parameter

43

PARAMETER_SET

Parameter set (not imported)

44

IMPLEMENTATION_LIST

Implementation list container

45

IMPLEMENTATION

Implementation (footprint link)

46

MAP_DEFINER_LIST

Map definer list (not imported)

47

MAP_DEFINER

Map definer (not imported)

48

IMPL_PARAMS

Implementation parameters (not imported)

209

NOTE

Note (text frame variant with author)

211

COMPILE_MASK

Compile mask (not imported)

215

HARNESS_CONNECTOR

Harness connector frame

216

HARNESS_ENTRY

Harness entry (port within connector)

217

HARNESS_TYPE

Harness type label

218

SIGNAL_HARNESS

Signal harness wire

225

BLANKET

Blanket region (not imported)

226

HYPERLINK

Hyperlink (label variant with URL)

Record IDs 19-21, 23-24, 35-36, 38, 40, 42, and 49-208 are either unassigned or undocumented.

Property Map Keys

All records are parsed into a std::map<wxString, wxString> of property keys and values. The following sections describe the primary keys for major record types.

Common Owner Properties

Most records carry ownership and display-mode properties:

Key Type Description

OWNERINDEX

int

Index of the parent component (-1 if sheet-level)

OWNERPARTID

int

Part ID within a multi-part symbol (-1 if unassigned)

OWNERPARTDISPLAYMODE

int

Display mode for the owning part

INDEXINSHEET

int

Unique index of this record within the sheet

ISNOTACCESIBLE

bool

Whether the record is accessible

COMPONENT (Record 1)

Key Type Description

LIBREFERENCE

string

Library reference name

SOURCELIBRARYNAME

string

Source library filename

COMPONENTDESCRIPTION

string

Component description text

UNIQUEID

string

Unique identifier string

CURRENTPARTID

int

Currently selected part ID

ORIENTATION

int

Rotation in 90-degree increments (0-3)

ISMIRRORED

bool

Whether the symbol is mirrored

LOCATION.X

int

X position in mils

LOCATION.Y

int

Y position in mils

LOCATION.X_FRAC

int

X fractional position

LOCATION.Y_FRAC

int

Y fractional position

PARTCOUNT

int

Number of parts in symbol

DISPLAYMODECOUNT

int

Number of display modes

DISPLAYMODE

int

Active display mode

PIN (Record 2)

Key Type Description

NAME

string

Pin name

TEXT

string

Pin display text

DESIGNATOR

string

Pin number designator

ELECTRICAL

int

Electrical type (0=input, 1=bidi, 2=output, 3=OC, 4=passive, 5=tristate, 6=OE, 7=power)

ORIENTATION

int

Pin direction (0=right, 1=up, 2=left, 3=down)

LOCATION.X

int

Pin position X in mils

LOCATION.Y

int

Pin position Y in mils

PINLENGTH

int

Pin stub length in mils

SYMBOL_OUTER

int

Outer symbol type

SYMBOL_INNER

int

Inner symbol type

SYMBOL_OUTEREDGE

int

Outer edge symbol type

SYMBOL_INNEREDGE

int

Inner edge symbol type

SHOWPINNAME

bool

Whether pin name is visible

SHOWDESIGNATOR

bool

Whether pin designator is visible

ISHIDDEN

bool

Whether pin is hidden

LOCKED

bool

Whether pin is locked

Pin symbol types map to graphical indicators (negation bubble, clock edge, etc.) using the ASCH_PIN_SYMBOL enumeration with values 0-34.

SHEET (Record 31)

Key Type Description

SHEETSTYLE

int

Sheet size enum (0=A4, 5=A, 10=Letter, etc.)

USECUSTOMSHEET

bool

Whether a custom sheet size is used

CUSTOMX

int

Custom sheet width in mils

CUSTOMY

int

Custom sheet height in mils

WORKSPACEORIENTATION

int

0=landscape, 1=portrait

FONTIDn

int

Font ID for font slot n

SIZEn

int

Font size for slot n

ITALICn

bool

Italic flag for font slot n

BOLDn

bool

Bold flag for font slot n

FONTNAMEn

string

Font name for slot n

Sheet size enumeration:

ID Size Name Dimensions (mils)

0

A4

1150 x 760

1

A3

1550 x 1110

2

A2

2230 x 1570

3

A1

3150 x 2230

4

A0

4460 x 3150

5

A

950 x 750

6

B

1500 x 950

7

C

2000 x 1500

8

D

3200 x 2000

9

E

4200 x 3200

10

Letter

1100 x 850

11

Legal

1400 x 850

12

Tabloid

1700 x 1100

13

OrCAD A

990 x 790

14

OrCAD B

1540 x 990

15

OrCAD C

2060 x 1560

16

OrCAD D

3260 x 2060

17

OrCAD E

4280 x 3280

Storage Stream Format

The Storage stream contains embedded binary files (typically images). Each entry is structured as:

[5 bytes skipped]                                                (1)
[1 byte length] [filename string]                                (2)
[4 bytes uint32] data_size                                       (3)
[data_size bytes] raw file data                                  (4)
1 Five header bytes of unknown purpose are skipped.
2 A Pascal-style string (length-prefixed) containing the filename.
3 A 32-bit unsigned integer specifying the byte count of the embedded data.
4 The raw file content.

In the ASCII variant, storage entries use NAME, DATA_LEN, and DATA (hex-encoded) properties.

Color Encoding

Colors throughout the schematic format are stored as 24-bit integers in BGR byte order:

red   = color & 0x0000FF
green = (color & 0x00FF00) >> 8
blue  = (color & 0xFF0000) >> 16

PCB Format (.PcbDoc)

Altium PCB files use the CFB container with a directory-per-object-type structure. Each directory typically contains two streams: a Header stream (holding a record count as a uint32_t) and a Data stream (holding the actual records).

Compound File Directory Structure

The PCB compound file contains the following top-level directories:

Directory Name Parse Format Description

FileHeader

Special

File version and identification

Arcs6

Binary

Arc primitives

Board6

Text Props

Board outline, stackup, and sheet settings

BoardRegions

Binary

Board region definitions

Classes6

Text Props

Net classes and component classes

ComponentBodies6

Binary+Props

3D body definitions for components

Components6

Text Props

Component (footprint) instances

Connections6

 — 

Ratsnest connections (not imported)

Coordinates6

 — 

Coordinate markers (not imported)

Dimensions6

Text Props

Dimension annotations

DifferentialPairs6

 — 

Differential pair definitions (not imported)

EmbeddedBoards6

 — 

Embedded board panels (not imported)

EmbeddedFonts6

 — 

Embedded font data (not imported)

Embeddeds6

 — 

General embedded objects (not imported)

ExtendedPrimitiveInformation

Text Props

Per-primitive mask expansion overrides

FileVersionInfo

 — 

File version metadata (not imported)

Fills6

Binary

Filled rectangle primitives

FromTos6

 — 

From-to definitions (not imported)

Models

Text Props

3D model references and embedded model data

ModelsNoEmbed

 — 

Non-embedded model references (not imported)

Nets6

Text Props

Net definitions

Pads6

Binary

Pad primitives (multi-subrecord)

PadViaLibrary

 — 

Pad/via library (not imported)

PadViaLibraryCache

 — 

Pad/via cache (not imported)

PadViaLibraryLinks

 — 

Pad/via links (not imported)

PinSwapOptions6

 — 

Pin swap settings (not imported)

PinPairsSection

 — 

Pin pair definitions (not imported)

Polygons6

Text Props

Copper polygon pour definitions

Regions6

Binary

Copper region (pour result) primitives

Rules6

Text Props

Design rules

ShapeBasedComponentBodies6

 — 

Shape-based 3D bodies (not imported directly)

ShapeBasedRegions6

Binary

Shape-based region primitives (keepouts, cutouts)

SignalClasses

 — 

Signal class definitions (not imported)

SmartUnions

 — 

Smart union definitions (not imported)

Texts

 — 

Legacy text (not imported)

Texts6

Binary

Text primitives

Textures

 — 

Board textures (not imported)

Tracks6

Binary

Track (trace) primitives

UnionNames

 — 

Union name definitions (not imported)

UniqueIDPrimitiveInformation

 — 

Unique ID mappings (not imported)

Vias6

Binary

Via primitives

WideStrings6

Binary

UTF-16 string table for text objects

Directories marked "not imported" are either unused by the importer or have no KiCad equivalent.

The compound file directory tree follows a consistent pattern:

PcbDoc.PcbDoc (CFB)
 +-- FileHeader/
 +-- Arcs6/
 |    +-- Header   (uint32_t record count)
 |    +-- Data     (binary arc records)
 +-- Board6/
 |    +-- Header
 |    +-- Data     (text property records)
 +-- Components6/
 |    +-- Header
 |    +-- Data     (text property records)
 +-- Fills6/
 |    +-- Header
 |    +-- Data     (binary fill records)
 +-- Nets6/
 |    +-- Header
 |    +-- Data     (text property records)
 +-- Pads6/
 |    +-- Header
 |    +-- Data     (binary multi-subrecord pad records)
 +-- Polygons6/
 |    +-- Header
 |    +-- Data     (text property records)
 +-- Regions6/
 |    +-- Header
 |    +-- Data     (binary region records)
 +-- Rules6/
 |    +-- Header
 |    +-- Data     (text property records)
 +-- Texts6/
 |    +-- Header
 |    +-- Data     (binary text records)
 +-- Tracks6/
 |    +-- Header
 |    +-- Data     (binary track records)
 +-- Vias6/
 |    +-- Header
 |    +-- Data     (binary via records)
 +-- WideStrings6/
 |    +-- Data     (UTF-16 string table)
 +-- Models/
 |    +-- Data     (text property model refs)
 |    +-- 0, 1, 2...  (compressed STEP model data)
 +-- ...            (additional directories)

Parse Format Types

The PCB format uses two distinct record encoding schemes within the Data streams:

Text Properties

Records are encoded as pipe-delimited key-value property strings. The ReadProperties() method reads a length-prefixed block and splits it into a property map. Used for Board6, Classes6, Components6, Dimensions6, Models, Nets6, Polygons6, Rules6, and ExtendedPrimitiveInformation.

Binary Records

Records begin with a uint8_t record type identifier followed by one or more length-prefixed subrecords. Each subrecord starts with a uint32_t byte count. Used for Arcs6, Fills6, Pads6, Regions6, ShapeBasedRegions6, Texts6, Tracks6, Vias6, and ComponentBodies6.

The Header stream for each directory contains a single uint32_t specifying the number of records in the Data stream.

Binary Record Type Identifiers

Binary record streams use a one-byte type tag at the start of each record:

ID Record Type

1

ARC

2

PAD

3

VIA

4

TRACK

5

TEXT

6

FILL

11

REGION

12

MODEL

Track Binary Layout (Tracks6)

Each track record contains a single subrecord:

uint8_t   record_type                                            (1)
uint32_t  subrecord_length                                       (2)
uint8_t   layer_v6                                               (3)
uint8_t   flags1                                                 (4)
uint8_t   flags2                                                 (5)
uint16_t  net                                                    (6)
uint16_t  polygon                                                (7)
uint16_t  component                                              (8)
[4 bytes] padding
int32_t   start_x, start_y                                       (9)
int32_t   end_x, end_y                                           (10)
int32_t   width                                                  (11)
uint16_t  subpolyindex                                           (12)
uint8_t   unknown
[optional: 5 bytes padding + uint32_t layer_v7]                  (13)
[optional: uint8_t keepout_restrictions]                          (14)
1 Record type (always 4 for tracks).
2 Length of the following subrecord data.
3 Layer ID in legacy V6 numbering.
4 Flags: bit 2 clear = locked, bit 1 set = polygon outline.
5 Flags: value 2 = keepout.
6 Net index (0xFFFF = unconnected).
7 Parent polygon index (0xFFFF = none).
8 Parent component index (0xFFFF = none).
9 Start point coordinates in Altium internal units.
10 End point coordinates in Altium internal units.
11 Track width in Altium internal units.
12 Sub-polygon index for polygon outline tracks.
13 V7 layer ID (uint32_t) present in newer file versions.
14 Keepout restriction flags (5 bits for track, via, copper, SMD, component).

Arc Binary Layout (Arcs6)

Arc records share the same initial structure as tracks:

uint8_t   record_type (= 1)
uint32_t  subrecord_length
uint8_t   layer_v6
uint8_t   flags1
uint8_t   flags2
uint16_t  net
uint16_t  polygon
uint16_t  component
[4 bytes] padding
int32_t   center_x, center_y                                     (1)
int32_t   radius                                                 (2)
double    start_angle                                             (3)
double    end_angle                                               (4)
int32_t   width                                                  (5)
uint16_t  subpolyindex
[optional V7/V8 extension fields]
1 Center point in Altium internal units.
2 Arc radius in Altium internal units.
3 Start angle in degrees (IEEE 754 double).
4 End angle in degrees.
5 Arc stroke width.

Via Binary Layout (Vias6)

Via records use a single subrecord with variable length depending on file version:

uint8_t   record_type (= 3)
uint32_t  subrecord_length
uint8_t   unknown
uint8_t   flags1                                                 (1)
uint8_t   flags2
uint16_t  net
[8 bytes] padding
int32_t   position_x, position_y
int32_t   diameter                                                (2)
int32_t   hole_size                                               (3)
uint8_t   layer_start                                             (4)
uint8_t   layer_end                                               (5)
1 Flags: bit 7 = test fab top, bit 6 = tent bottom, bit 5 = tent top, bit 2 clear = locked.
2 Via annular ring diameter in Altium internal units.
3 Drill hole diameter.
4 Start layer ID.
5 End layer ID.

Extended via records (subrecord length > 74) contain fields for thermal relief, solder mask expansion, via pad mode, and per-layer diameter arrays (32 entries).

Pad Binary Layout (Pads6)

Pads use a multi-subrecord structure with six subrecords:

uint8_t   record_type (= 2)

Subrecord 1: pad name (Pascal string)
Subrecord 2: unknown (skipped)
Subrecord 3: unknown (skipped)
Subrecord 4: unknown (skipped)

Subrecord 5 (>= 110 bytes):                                      (1)
  uint8_t   layer_v6
  uint8_t   flags1                                                (2)
  uint8_t   flags2
  uint16_t  net
  [2 bytes] padding
  uint16_t  component
  [4 bytes] padding
  int32_t   position_x, position_y
  int32_t   top_size_x, top_size_y                                (3)
  int32_t   mid_size_x, mid_size_y
  int32_t   bot_size_x, bot_size_y
  int32_t   hole_size
  uint8_t   top_shape                                             (4)
  uint8_t   mid_shape
  uint8_t   bot_shape
  double    direction (rotation in degrees)
  uint8_t   plated
  [1 byte]  padding
  uint8_t   pad_mode                                              (5)
  [23 bytes] padding
  int32_t   paste_mask_expansion
  int32_t   solder_mask_expansion
  [7 bytes] padding
  uint8_t   paste_mask_mode
  uint8_t   solder_mask_mode
  ...extended fields for hole rotation, layer span, pad-to-die

Subrecord 6 (>= 596 bytes): size and shape data                  (6)
  int32_t   inner_size_x[29]
  int32_t   inner_size_y[29]
  uint8_t   inner_shape[29]
  [1 byte]  padding
  uint8_t   hole_shape
  int32_t   slot_size
  double    slot_rotation
  int32_t   hole_offset_x[32]
  int32_t   hole_offset_y[32]
  [1 byte]  padding
  uint8_t   alt_shape[32]
  uint8_t   corner_radius[32]
1 Main pad geometry subrecord.
2 Flags: bit 7 = test fab top, bit 6 = tent bottom, bit 5 = tent top, bit 2 clear = locked.
3 Pad size for top, middle, and bottom layers (used when pad mode is TOP_MIDDLE_BOTTOM).
4 Pad shape: 1 = circle, 2 = rectangle, 3 = octagonal.
5 Pad mode: 0 = simple, 1 = top/middle/bottom, 2 = full stack.
6 Extended shape data including per-layer inner sizes, hole geometry, and corner radii.

Fill Binary Layout (Fills6)

uint8_t   record_type (= 6)
uint32_t  subrecord_length
uint8_t   layer_v6
uint8_t   flags1
uint8_t   flags2
uint16_t  net
[2 bytes] padding
uint16_t  component
[4 bytes] padding
int32_t   pos1_x, pos1_y                                         (1)
int32_t   pos2_x, pos2_y                                         (2)
double    rotation                                                (3)
1 First corner of the fill rectangle.
2 Opposite corner.
3 Rotation angle in degrees.

Text Binary Layout (Texts6)

Text records use a single subrecord with variable-length fields:

uint8_t   record_type (= 5)
uint32_t  subrecord_length
uint8_t   layer_v6
[6 bytes] padding
uint16_t  component
[4 bytes] padding
int32_t   position_x, position_y
int32_t   height                                                  (1)
uint16_t  stroke_font_type                                        (2)
double    rotation
uint8_t   is_mirrored
int32_t   stroke_width
1 Text height in Altium internal units.
2 Stroke font type: 1 = default, 2 = sans-serif, 3 = serif.

Extended text records (subrecord length >= 123 bytes) add:

  • is_comment / is_designator flags

  • Font type (0 = stroke, 1 = TrueType, 2 = barcode)

  • Bold, italic flags

  • 64-byte UTF-16LE font name

  • Inverted text flag

  • Text box dimensions and justification

  • Wide string table index (for UTF-16 text via WideStrings6)

  • Barcode parameters (type, margins, font)

  • V7 layer ID

WideStrings6

The WideStrings6 directory contains a UTF-16 string table used by text objects. The Data stream stores sequential entries:

uint32_t  index                                                   (1)
uint32_t  byte_length                                             (2)
[byte_length bytes] UTF-16LE string data                          (3)
1 String table index referenced by ATEXT6::widestring_index.
2 Total byte length including null terminator (0 or 2 bytes for empty strings).
3 UTF-16LE encoded string data.

Layer Numbering

Altium uses three generations of layer numbering. All three may appear within the same file. The importer resolves V7 mechanical layers to their extended IDs and falls back to V6 IDs for standard layers.

Legacy Layer IDs (V6)

ID Range Layer Group Details

1

Top Layer

Front copper

2-31

Mid Layer 1-30

Internal copper layers

32

Bottom Layer

Back copper

33

Top Overlay

Front silkscreen

34

Bottom Overlay

Back silkscreen

35

Top Paste

Front solder paste

36

Bottom Paste

Back solder paste

37

Top Solder

Front solder mask

38

Bottom Solder

Back solder mask

39-54

Internal Plane 1-16

Power/ground plane layers

55

Drill Guide

Drill guide layer

56

Keep-Out Layer

Board keepout boundary

57-72

Mechanical 1-16

User-defined mechanical layers

73

Drill Drawing

Drill drawing layer

74

Multi-Layer

All-layer objects (through-hole pads)

75-82

System layers

Connections, background, DRC markers, grids, holes

V7 Extended Layers

V7 format uses 32-bit layer IDs with a base offset:

Base + Offset Layer

0x01000000 + 1

V7 Top Layer

0x01000000 + 65535

V7 Bottom Layer

0x01020000 + 1..N

V7 Mechanical 1 through Mechanical N (supports > 16 mechanical layers)

V7 mechanical layers beyond 16 are stored with IDs in the 0x01020000 range. The parser reads the LAYER_V7 property from text-format records or the V7 layer field from binary subrecord extensions to resolve these.

V8 Extended Layers

V8 format adds further layer IDs under the 0x01030000 base:

Offset Layer

+6

Top Overlay

+7

Bottom Overlay

+8

Top Paste

+9

Bottom Paste

+10

Top Solder

+11

Bottom Solder

+12

Drill Guide

+13

Keep-Out Layer

+14

Drill Drawing

+15

Multi-Layer

+16

Connections

+17

Background

+18

DRC Error Markers

+19

Selections

+20

Visible Grid 1

+21

Visible Grid 2

+22

Pad Holes

+23

Via Holes

+24

Top Pad Master

+25

Bottom Pad Master

+26

DRC Detail Markers

Mechanical Layer Kind Mapping

Newer Altium files assign semantic meaning to mechanical layers through a MECHKIND property. The importer uses this to map mechanical layers to appropriate KiCad layers:

Hex ID Kind Name Description

0x01

AssemblyTop

Top assembly drawing

0x02

AssemblyBottom

Bottom assembly drawing

0x03

AssemblyNotes

Assembly notes

0x04

Board

Board outline

0x05

CoatingTop

Top conformal coating

0x06

CoatingBottom

Bottom conformal coating

0x07

ComponentCenterTop

Top component center marks

0x08

ComponentCenterBottom

Bottom component center marks

0x09

ComponentOutlineTop

Top component outline (courtyard)

0x0A

ComponentOutlineBottom

Bottom component outline

0x0B

CourtyardTop

Top courtyard

0x0C

CourtyardBottom

Bottom courtyard

0x0D

DesignatorTop

Top designator text

0x0E

DesignatorBottom

Bottom designator text

0x0F

Dimensions

Dimension annotations

0x10

DimensionsTop

Top-specific dimensions

0x11

DimensionsBottom

Bottom-specific dimensions

0x12

FabNotes

Fabrication notes

0x13

GluePointsTop

Top glue points

0x14

GluePointsBottom

Bottom glue points

0x15

GoldPlatingTop

Top gold plating areas

0x16

GoldPlatingBottom

Bottom gold plating areas

0x17

ValueTop

Top component value text

0x18

ValueBottom

Bottom component value text

0x19

VCut

V-cut scoring

0x1A

3DBodyTop

Top 3D body layer

0x1B

3DBodyBottom

Bottom 3D body layer

0x1C

RouteToolPath

Routing tool path

0x1D

Sheet

Drawing sheet border

0x1E

BoardShape

Board shape definition

Board6 Properties

The Board6 directory stores board-level settings as text properties. Key fields:

Key Type Description

SHEETX

unit

Sheet origin X

SHEETY

unit

Sheet origin Y

SHEETWIDTH

unit

Sheet width

SHEETHEIGHT

unit

Sheet height

LAYERSETSCOUNT

int

Number of signal layer pairs (total copper = value + 1)

LAYERnNAME

string

Name of layer n in the stackup

LAYERnCOPTHICK

unit

Copper thickness for layer n

LAYERnDIELCONST

double

Dielectric constant for layer n

LAYERnDIELHEIGHT

unit

Dielectric thickness for layer n

LAYERnDIELMATERIAL

string

Dielectric material name (e.g., "FR-4")

LAYERnMECHENABLED

string

"TRUE" or "FALSE" for mechanical layer visibility

LAYERnMECHKIND

string

Mechanical layer kind (e.g., "CourtyardTop")

VXn, VYn

unit

Board outline vertex coordinates

KINDn

int

Vertex type (0 = line, nonzero = arc)

Rn, SAn, EAn

various

Arc vertex radius, start angle, end angle

CXn, CYn

unit

Arc vertex center point

V7 format files use LAYERV7_n prefixed keys for extended layer stackup properties.

The LAYERnLAYERID key (V7 only) carries the 32-bit layer identifier used in the extended layer numbering scheme.

Design Rules (Rules6)

Rules are stored as text-format property records in the Rules6 directory. Each rule has a RULEKIND property:

Rule Kind Key Properties

Clearance

GAP (clearance distance)

DiffPairsRouting

Differential pair routing parameters

Height

Component height constraints

HoleSize

MINLIMIT, MAXLIMIT

HoleToHoleClearance

GAP

Width

MINLIMIT, MAXLIMIT, PREFERREDWIDTH

PasteMaskExpansion

EXPANSION

SolderMaskExpansion

EXPANSION

PlaneClearance

CLEARANCE

PolygonConnect

CONNECTSTYLE, AIRGAPWIDTH, RELIEFCONDUCTORWIDTH, RELIEFENTRIES

RoutingVias

WIDTH, MINWIDTH, MAXWIDTH, HOLEWIDTH, MINHOLEWIDTH, MAXHOLEWIDTH

Each rule also carries NAME, PRIORITY, SCOPE1EXPRESSION, and SCOPE2EXPRESSION properties that define the rule’s name, evaluation priority, and applicability scope.

Region Kinds

The ShapeBasedRegions6 directory stores regions with a KIND property and additional flags:

Kind Enum Value Description

0

COPPER

Copper region (or board cutout when ISBOARDCUTOUT=TRUE)

1

POLYGON_CUTOUT

Cutout within a copper polygon

2

DASHED_OUTLINE

Dashed outline region

3

UNKNOWN_3

Unknown

4

CAVITY_DEFINITION

Board cavity definition

5

BOARD_CUTOUT

Board cutout (derived from KIND=0 + ISBOARDCUTOUT flag)

Project Format (.PrjPcb)

Altium project files use a standard Windows INI-style text format. The importer parses the file using the ALTIUM_ASCII_PARSER class, which reads key-value properties.

Key sections and entries:

[Design]
DocumentPath=path\to\schematic.SchDoc                            (1)
DocumentPath=path\to\board.PcbDoc                                (2)
DocumentPath=path\to\library.SchLib                              (3)
1 Schematic document references. Multiple entries list all project sheets.
2 PCB layout file reference.
3 Library file references.

The importer resolves paths relative to the project file location and handles both forward and backward slashes. All .SchDoc files are imported as a multi-sheet schematic hierarchy, and the first .PcbDoc file becomes the board.

Library Formats

Schematic Library (.SchLib)

A .SchLib file is a CFB container where each symbol is stored as a named directory. Each symbol directory contains:

  • A record stream with the symbol’s graphical primitives (same record format as .SchDoc)

  • Optional PinsFrac, PinsWideText, PinsTextData, and PinsSymbolLineWidth streams for extended pin data

The GetLibSymbols() method enumerates symbol directories by walking the CFB tree structure.

PCB Library (.PcbLib)

A .PcbLib file is a CFB container where each footprint is stored as a named directory. Each footprint directory mirrors the PCB file structure with subdirectories for Arcs6, Pads6, Tracks6, Texts6, etc.

The library root additionally contains:

  • A Library directory with a Data stream holding library-level stackup properties

  • A Models directory with a Data stream of AMODEL records and numbered streams containing compressed 3D model data (STEP files)

Each footprint directory contains a Parameters stream with a PATTERN property holding the footprint name.

Integrated Library (.IntLib)

An .IntLib file is a CFB container wrapping both schematic and PCB libraries. The container holds:

  • SchLib directory entries, each containing a compressed or uncompressed .SchLib file

  • PCBLib directory entries, each containing a compressed .PcbLib file

Each embedded library stream begins with a type byte: 0x02 for zlib-compressed data or 0x00 for uncompressed. The DecodeIntLibStream() method handles decompression and creates a new ALTIUM_COMPOUND_FILE from the decoded data.

Imported Elements

Schematic (.SchDoc)

  • Components with symbol graphics, pins, and multi-part/multi-display-mode support

  • Wires, buses, bus entries, and junctions

  • Net labels, power ports, and ports (inter-sheet connectors)

  • Sheet symbols and sheet entries for hierarchical design

  • Harness connectors, harness entries, and signal harness wires

  • Lines, rectangles, polygons, polylines, arcs, circles, ellipses, elliptical arcs, rounded rectangles, bezier curves, and pie chart arcs

  • Text frames, notes, and hyperlinks

  • Embedded images from the Storage stream

  • Parameters as component fields

  • No-ERC markers

  • Design hierarchy from .PrjPcb project files (multi-sheet import)

PCB (.PcbDoc)

  • Tracks with width, net, and layer assignment

  • Arcs with center, radius, start/end angles, and width

  • Vias with diameter, hole size, start/end layer, and tenting flags

  • Pads with per-layer shapes (circle, rectangle, octagonal), sizes, hole geometry, and solder mask/paste expansion

  • Fills as rotated rectangles

  • Text with stroke and TrueType fonts, mirroring, and UTF-16 wide strings

  • Copper polygon pour definitions and region fill results

  • Shape-based regions (keepouts, cutouts, board cutouts, cavity definitions)

  • Board outline from Board6 vertex properties

  • Layer stackup from Board6 properties including copper thickness, dielectric constants, and material names

  • Net definitions and net-to-object assignment

  • Component placements with rotation and layer

  • Design rules (clearance, width, hole size, mask expansion, polygon connect, routing vias, diff pairs, plane clearance)

  • 3D model references and embedded compressed STEP model data

  • Dimension annotations

  • Component body definitions

  • Per-primitive mask expansion overrides from ExtendedPrimitiveInformation

Library (.SchLib, .PcbLib, .IntLib)

  • SchLib symbol directories with graphical primitives and extended pin data

  • PcbLib footprint directories mirroring the PCB file structure

  • IntLib integrated libraries with zlib-compressed SchLib and PcbLib streams

  • Library-level stackup properties and embedded 3D model data

Limitations

  • Pad shapes beyond circle (1), rectangle (2), octagonal (3), and rounded rectangle (9) are not recognized.

  • Code page handling for older files defaults to ISO-8859-1; the original code page is not preserved.

  • ExtendedPrimitiveInformation only parses the Mask type; other types are ignored.

  • Several PCB directories are not imported: AdvancedPlacerOptions6, PadViaLibrary, PadViaLibraryCache, PadViaLibraryLinks, PinSwapOptions6, SmartUnions, Textures, UniqueIDPrimitiveInformation.

  • 3D package instance placement data is read but not applied.

  • SPICE model data in schematics is parsed but not imported into KiCad’s simulation framework.

  • IEEE standard symbols (record 3), parameter sets (record 43), map definers (records 46-47), implementation parameters (record 48), compile masks (record 211), and blankets (record 225) are not imported.

Undocumented and Partially Understood Areas

The following aspects of the Altium format remain incompletely understood:

  • The exact encoding of code pages for string data in older files. Recent versions use a UTF-16 string table (WideStrings6), but older files rely on an unspecified code page. The importer defaults to ISO-8859-1.

  • The purpose of several padding and unknown bytes in binary record subrecords, particularly in Pads6 subrecords 2-4 and various skip regions.

  • The complete set of ExtendedPrimitiveInformation types. Only the Mask type (per-primitive solder/paste mask expansion overrides) is currently parsed.

  • Several PCB directories exist in files but are not parsed: AdvancedPlacerOptions6, PadViaLibrary, PadViaLibraryCache, PadViaLibraryLinks, PinSwapOptions6, SmartUnions, Textures, UniqueIDPrimitiveInformation.

  • The precise semantics of vertex encoding in polygon outlines, particularly the interaction between arc vertices (with center, radius, start/end angles) and their positional vertices.

  • Text records contain multiple unknown byte regions between known fields, especially in extended-length subrecords containing barcode data.

  • The full set of ALTIUM_PAD_SHAPE_ALT values beyond circle (1), rectangle (2), octagonal (3), and rounded rectangle (9).