0hmx - Maybe this is how trace names should be ...

yea i agree w/ that

not sure what those should be called (maybe <@1525187702029549659> knows)

ahh he alredy shared a pretty big ans to this a while ago

Yes, I've already created a spec last week: https://github.com/tscircuit/core/issues/2934

More details in this thread: https://community.tscircuit.com/thread/1532067569459265661

TL;DR: EasyEDA calls this netLabel, while what tscircuit calls netLabel is actually netPort. The GND/VCC are neither called netlabels not netports, those are called "supply flags" and treated as schematic components with their own schematic symbol editing rather than pure text labels.

the actual net labels work similarly to tscircuit net port treatment. The only difference is x/y origin points to the left bottom corner of the text element, while netport's x.y origin points to the symbol anchor

So the changes would require: - introduce `<netport` as a schematic component, with a way to specify the schematic symbol with its own origin point and a text - change `<netlabel>` behaviour by pushing the anchor side property into `<netport>` and removing the port symbol, leaving only text. The only problem is that x.y of netlabel now must be on the wire. So instead of specifying that fixed coordinate, I propose removing x.y props from `<netlabel` and instead provide the percentage [0,1] length of total manhatten style wire lenght and the margin/distance to the wire.

To simiulate the GND/VCC behaviour right now, we can use schematicbox with custom symbol and fixed port side (top for GND, bottom for VCC)

Net port can be done similarly using schematicbox, but that one carries implicit semantic meaning that influence how `<subcircuit` works. In fact, netlabel with wormhole (no netport symbol, just a net without routing) I think is what tscircuit `<port` is trying to model.

We should call it an inline netlabel maybe

netport etc i dont think that’s inherently more semantically meaningful, wormhole is opinionated Also curious how kicad designates

If I were to design this from scratch I'd separate concerns

schematic text with coordinates is probably something circuitjson supports?

yeah, we have `<schematictext`: https://docs.tscircuit.com/elements/schematictext

the problem with schematic text is that we don't know where the wire is: `circuitjson` doesn't provide resulting wire segments after routing, so we can't place that schematictext on a wire. So we need some `<textplacer` component that would allow authors to put out a trace after the routing is completed. Alternatively, there should be explicit `sch_wiretext` or something like that which allows to tell placer/router to put the text near the end of the wire, with appropriate margins

once we have abstract capability to put out a text on a wire, we can compose higher level abstractions and make that capability *mean* something

for example, we might tie together `<net name`, `<trace name` and `<netlabel name` into highlevel "net segment name" or "power rail name" or "signal name" abstraction and use that abstract name to put a text on a wire automatically or manually (and possibly on silksreen text, etc).

KiCAD has offset property of the plain text label

So the concern levels are: - authoring - logical scope and conflict resolution - placer/routing algorithm - visual representation