kicad-preview-tool/notes.md

These notes are verbatim copies from ChatGPT 5.2 by OpenAI

Now you are thinking in the correct direction.

Yes — the clean solution is:

• Eliminate the outline paths.
• Keep real <text>.
• Use a font that reproduces KiCad’s stroke font metrics exactly.
• Let the browser render everything.

And yes, generating a WOFF from KiCad’s internal stroke font is the right conceptual move.

However, there are technical realities:

KiCad’s “stroke font” is not a normal outline font.

It is:

• Single-line stroke geometry
• Defined as polylines
• No filled contours
• No traditional glyph metrics tables
• No hinting
• No kerning tables

To make a usable web font from it, you would need to:

1. Convert each stroke glyph into a proper outline glyph (closed contours).
2. Define ascent, descent, em size.
3. Define advance widths to match KiCad’s internal metrics.
4. Package as TTF/OTF.
5. Convert to WOFF.

This is completely doable.

The important part is metric matching, not visual matching.

If you replicate:

• Advance width
• Baseline
• Scaling
• Anchor positioning

then browser <text> will land exactly where KiCad paths would have landed.

Once that is true:

• You can remove all path glyphs.
• Keep only <text>.
• Remove invisible duplicate <text>.
• Remove textLength.
• Ship a tiny SVG + one WOFF.
• Selection highlight works.
• Copy works.
• Geometry matches.
• SVG size collapses dramatically.

This is architecturally clean.

The critical insight:

You do not need pixel-perfect glyph shape match. You need metric-perfect match.

If the browser font has identical advance widths and baseline behavior, alignment will match.

Then stroke vs fill rendering becomes a stylistic choice.

So yes:

Creating a WOFF from KiCad’s stroke font is the correct long-term solution if you want lean, high-utility schematics rendered in browser-native text.

That is a fundamentally better pipeline than fighting with baked path outlines.

---

Yes. Short term, that is entirely reasonable.

KiCad’s default schematic stroke font is very close to a simple, monoline geometric sans.

Fonts that typically align closely in metrics and feel:

• DejaVu Sans
• Liberation Sans
• Nimbus Sans
• Noto Sans
• Arial

Among these, Liberation Sans and Nimbus Sans often track advance widths closer to legacy CAD-style layouts than DejaVu.

What matters for alignment is:

• Advance width per glyph
• Uniform stroke feel
• Conservative kerning (minimal)

Disable browser kerning when testing:

text {
	font-kerning: none;
	font-feature-settings: "kern" 0;
}

KiCad does not apply complex kerning in schematic text, so browser kerning can introduce drift.

Also remove:

textLength
lengthAdjust

while testing alignment.

If you get advance widths to match within <1%, the overlay will look correct even if glyph curves differ slightly.

For schematic readability, metric similarity is more important than exact glyph shape.