File formats
Every Kaleidoscope Plan file type — what it stores, its UTI and MIME type, and how the formats stay stable.
Kaleidoscope Plan uses open, JSON-based files with registered Uniform Type Identifiers, so the system routes them straight to the app via Open With in Files, Mail and AirDrop.
The formats
| Extension | Name | Contents | MIME type |
|---|---|---|---|
.kalar | Drawing | A building with floors, rooms, walls, openings, fittings, lights and heating | application/x-kalar |
.kalarelement | Element | A reusable fixture or furniture symbol you defined | application/x-kalarelement |
.kalascan | Scan archive | A self-contained single-scan archive wrapping the raw RoomPlan capture | application/x-kalascan |
.kaliarchive | Project archive | A whole project — every drawing and scan — in one file | application/x-kaliarchive |
.kengine | Engine | A single engine overlay attached to a drawing | — |
Each registered type has a UTI of the form com.maritime.master.kaleidoscope-plan.<type>, conforming to public.json and public.content.
On disk vs. shareable archives
- A drawing is one
.kalarfile. - A scan lives on disk as a small folder (the raw capture plus metadata) inside its project, and can be exported as a single
.kalascanarchive. - A project lives on disk as a folder containing its drawings and scans, and can be exported as a single
.kaliarchivearchive. - An engine is a
.kenginefile saved next to the drawing it overlays.
How drawings are stored
A .kalar is structured JSON, written pretty-printed with sorted keys so it’s human-readable and diff-friendly. Everything is rendered procedurally from that data — no embedded images, no fixed scene graph — which is why plans stay crisp at any zoom and export size.
Round-trips are idempotent: saving and reloading preserves geometry exactly. Wall layer stacks are always written out (using the default if none was set), and optional fields are omitted when empty, so the file stays clean.
Coordinates and units
Geometry is stored in metres with a consistent coordinate system (see Coordinate system & units). Display units (metres, feet, millimetres) are a presentation choice and never change the stored values.
Forward compatibility
The schema is versioned and additive: new optional fields are introduced in a backward-compatible way, so newer files stay readable and older files keep working as the app evolves.