Skip to content

fix(sch): align add_schematic_text as KiCad does instead of centring it - #308

Open
anyn99 wants to merge 1 commit into
mixelpixx:mainfrom
anyn99:fix/schematic-text-justify
Open

fix(sch): align add_schematic_text as KiCad does instead of centring it#308
anyn99 wants to merge 1 commit into
mixelpixx:mainfrom
anyn99:fix/schematic-text-justify

Conversation

@anyn99

@anyn99 anyn99 commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

Closes #286.

Verified against KiCad 10.0.4 by re-running the reproduction from the issue — an
A3 sheet, one 61-character annotation at x = 27.94, size 5, exported with
kicad-cli sch export svg. Today the text is anchored middle and its left edge
lands at -84.65 mm, 84 mm off the page. With (justify left bottom) it is
anchored start and starts at 27.94 mm, where the caller asked for it.

left bottom is what KiCad 10 itself writes: in its bundled demo projects, every
(text ...) block in the current format version carries a justify clause, and
all of them are left bottom. That is the default this PR adopts.

The change

add_schematic_text gains a justify argument. It takes at most one horizontal
token (left, right) and one vertical token (top, bottom), in either
order and any case, and writes them in KiCad's order — horizontal first. An
unknown token, or two tokens on one axis, is refused rather than guessed at.

Alignment is per axis, and an axis left out is centred: "left" is
left-aligned and vertically centred, "bottom" is horizontally centred and
bottom-aligned. "center" centres both and so writes no clause. It is
also the behaviour before this change, which callers who want it keep by
asking.

This changes existing behaviour

Text placed through this tool is centred on x today and will be left-bottom
aligned after this PR. That is the point of the fix, but it is not a pure
addition: an existing caller's annotation moves. "center" is the opt-out.
There is no docs/API_MIGRATIONS.md on main yet — #278 adds one — so this
note is here instead.

Tests

Six: the new default, token order, "center" emitting nothing, the two
refusals, and a parser test over the shapes KiCad's own demos contain.

cargo test --no-fail-fast --workspace green, fmt and clippy clean.
tool-directory.md gains the parameter on the tool's row.

The handler wrote no `(justify ...)` clause, so KiCad centred the text on `x`.
A long line then crosses the page edge and is dropped from the PDF export while
the .kicad_sch still holds it intact and the tool reports success. Measured on
KiCad 10.0.4 with the reproduction from the issue: a 61-character annotation at
x = 27.94 lands with its left edge at -84.65 mm.

Add a `justify` argument, defaulting to `left bottom`. Alignment is per axis and
an axis left out is centred, which is how KiCad encodes it; `center` centres
both and writes no clause, the behaviour before this change. Unknown tokens and
two tokens on one axis are refused rather than guessed at.

`left bottom` is what KiCad itself writes: every `(text ...)` block in the
current format version of its bundled demos carries that clause.

Closes mixelpixx#286

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] add_schematic_text has no justification control, so long text is silently clipped out of the export

1 participant