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:

```css
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.