Initial commit

notes.md

@@ -0,0 +1,125 @@
+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.
+