Skip to content

fix: keep quad corner silkscreen clear of the pads (#734) - #735

Open
DPS0340 wants to merge 1 commit into
tscircuit:mainfrom
DPS0340:fix/quad-corner-silkscreen-clearance
Open

fix: keep quad corner silkscreen clear of the pads (#734)#735
DPS0340 wants to merge 1 commit into
tscircuit:mainfrom
DPS0340:fix/quad-corner-silkscreen-clearance

Conversation

@DPS0340

@DPS0340 DPS0340 commented Jul 25, 2026

Copy link
Copy Markdown
Contributor

Closes #734.

On narrow-body quad variants the corner marks were drawn through the pads. tqfp32_w7's top-left arm ran from x=-3.5 to x=-2.4 at y=3.5, while pad 32 occupies x[-3.075,-2.525] y[3.400,4.875] — straight over copper, at −0.05 mm clearance.

The fix

The corner sits at (±w/2, ±h/2), the pad-row centre line, so an arm running inward always crosses the band the outer pads occupy. It only stayed clear when the fixed csz = pw * 2 arm happened to be short enough — which is why the default tqfp32 looked fine and the 7 mm-body variant did not.

Rather than shifting the corner (which would move it off the body outline), this clamps each arm to stop before the first pad it would reach:

const silkPadClearance = 0.2 + SILK_STROKE_WIDTH / 2
const armX = maxArmLength(corner_x, corner_y, "x", -dx, csz)
const armY = maxArmLength(corner_x, corner_y, "y", -dy, csz)

maxArmLength walks the actual pad boxes (collected during pad generation, thermal pad included), keeps only those spanning the arm's perpendicular coordinate, and returns the distance to the nearest one. Arms that already clear everything keep their full csz length, so footprints that were correct are untouched — only 3 snapshots changed, and 2 of those are the reported defects.

Verification

Measured, not eyeballed. Segment-to-pad distance minus half the stroke:

                        before     after
tqfp32_w7              -0.0500    0.2000
tqfp48_w7              -0.0500    0.2000
qfp80_w14_h14_p0.65mm   0.1500    0.2000
tqfp32 (default)        0.5750    0.5750   ← unchanged
lqfp32                  0.4500    0.4500   ← unchanged
qfn32                   0.5829    0.5829   ← unchanged

0.2 mm is not an arbitrary target: I measured KiCad's own references first and they land on exactly that number — TQFP-32_7x7mm_P0.8mm, TQFP-48, TSSOP-10, SOT-457T all report 0.2000 mm silk-to-pad.

The new test bites. Reverting only src/fn/quad.ts:

-   "minClearance": true,
+   "minClearance": false,
(fail) quad corner silkscreen keeps clear of every pad

It covers 9 variants (narrow and default bodies, QFN, LQFP, QFP) and asserts cornerPaths.length > 0 so it can't pass vacuously. It deliberately excludes the pin 1 arrow (_3 paths), which is placed against the pad it identifies by design — I confirmed that arrow's 0.1 mm gap is unchanged from main and not something this PR introduces.

Suite: 468 pass / 0 fail, biome format clean, bun run build (ESM + DTS) ok. I rendered the tqfp32 parity snapshot and compared it with the KiCad reference side by side — the corner marks now sit in the gaps between pads exactly as KiCad's do, and courtyardDiffPercent stays 0.00%.

How this was found

Extended the #732/#733 silkscreen scan across all 90 parity footprints, comparing each against its KiCad reference. It surfaced 4 footprints with no silkscreen where KiCad has some, and 3 with actual overlap. This PR fixes the quad ones; #734 lists the rest (sod123, sot723, tssop10_w3mm_p0.5mm, sot457_w2_pl1.5_pw0.6), which come from different code paths and are better as separate PRs. Happy to send those next if this approach looks right.

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.

quad corner silkscreen is drawn over the pads on narrow-body variants (tqfp32_w7, tqfp48_w7)

1 participant