Faber Draw

Engineering sheets Faber can generate and you can edit, kept as a real object model rather than a picture of one.

The drawing surface | opens from any sheet in the preview pane

The idea

The sheet is the model, not the PDF

A drawing is stored as .faber-draw.json — every line, symbol, note, arrow head and title block is a named object with a stable id.

A PDF is derived output. It cannot be opened as source, and Faber will not convert one back into a drawing. That sounds like a limitation until the third revision, when the difference is between moving a tag and redrawing a sheet.

Two versions coexist. Version 1 stays for lightweight device, note and wire diagrams. Version 2 carries full engineering packages: the native sheet canvas, styled text, drawing primitives, and embedded logo marks held as selectable objects rather than an external file path — so a title block travels inside the model.

In Engineering Drawings mode the model is the deliverable. Every sheet is a native v2 model plus the package manifest before a PDF is considered at all. Arrow shafts and heads included — nothing visible is a flattened image.

Using it

Where it opens

Selecting a .faber-draw.json file in Faber opens a quick inspector in the normal preview pane — enough to look at a sheet Faber just generated. For v2 engineering sheets that preview is canvas-only at 150% with zoom controls, because fine notes are the first thing to become unreadable when a sheet is squeezed into a side pane.

Edit in Faber Draw opens the full workspace in a browser tab. That is the manual edit surface: an always-visible zoom control, text and line creation, tight object selection, paragraph editing for wrapped notes, and drag moves for both model versions.

Using it

Weight and shade carry meaning

On an Aberdeen sheet, heavy black is new work and lighter grey is existing to remain. That convention lives in the drawing, so the editor has to be able to set it.

Every stroked object exposes a numeric line weight with Thin, Medium and Heavy presets, and a shade row of New work, Existing and Light alongside a free colour picker. Text carries the same shade control plus Bold and Italic. Legacy v1 wires take weight and shade too — a older diagram marks new against existing the same way.

Selection is a set, not one object. Shift-click toggles, dragging from empty paper lassoes, Ctrl+A selects all, Esc clears. Drag any member and the whole set moves; nudge, duplicate, delete and every styling control apply to the selection. A style that cannot apply to an object — bold on a line — skips it, and the status line reports how many were actually touched.

Endpoint handles appear only on a single selection. Otherwise a multi-object drag could silently reshape one line instead of moving the group.

Using it

Rendering a PDF

Render PDF is explicit. Faber creates the print only when you ask for it, and you still name and confirm the destination. A package sheet renders through its manifest; a standalone sheet with no manifest renders beside itself.

Save and render outcomes announce themselves as a toast over the canvas. Success clears itself; an error stays until you dismiss it. The older status line read as decoration, which meant a save that worked and a save that silently failed looked identical.

How it fits

The Workspace companion

Faber Draw runs as a separate local service that Faber starts, supervises and embeds. It is first-party, but it is deliberately kept at arm's length.

The editor has no direct project or filesystem access. Faber remains the filesystem authority and hands the selected document over an origin-checked postMessage: the editor announces it is ready, Faber sends that one drawing to that one tab, and an explicit save request comes back. Faber validates the returned document and persists it atomically. A download-copy fallback exists if the handoff cannot complete.

The service runs on loopback under the same supervision as App Browser children, so a crashed or killed editor cannot leave an orphan process behind.

How it fits

Why it is built this way

Three decisions are worth knowing, because each one came from something going wrong.

The renderer is tested against itself. The font work is driven through the real PyMuPDF renderer rather than a stand-in, so a typeface the renderer would reject cannot ship.
Colour is validated on both model versions. It used to be checked on v2 only, which let a v1 colour reach a stylesheet that silently overrode it — the edit saved and showed nothing.
Selection is drawn as a dashed outline rather than by restyling the object. Highlighting a selection by changing its stroke hid the very weight and shade being edited.