126 lines
3.0 KiB
Markdown
126 lines
3.0 KiB
Markdown
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.
|
||
|