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

Channel: #contributor
Source: https://discord.com/channels/1233487248129921135/1534344316779237547
Started: 2026-08-04T23:36:32.521000+00:00
Last activity: 2026-08-05T15:01:51.926000+00:00

## 0hmx — 2026-08-04T23:36:31.859000+00:00

Maybe this is how trace names should be displayed, instead of adding a separate label for each trace name. I’m not sure, though.
Attachment: image.png — https://community.tscircuit.com/media/1534344316519186542

## 0hmx — 2026-08-04T23:37:21.610000+00:00

[attachment]
Attachment: image.png — https://community.tscircuit.com/media/1534344525223432383

## Seve — 2026-08-05T00:13:06.643000+00:00

yea i agree w/ that

## Seve — 2026-08-05T00:13:35.022000+00:00

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

## 0hmx — 2026-08-05T11:49:59.770000+00:00

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

## astrimid — 2026-08-05T13:39:56.055000+00:00

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

## astrimid — 2026-08-05T13:43:31.502000+00:00

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

## astrimid — 2026-08-05T13:54:49.730000+00:00

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.
Attachment: image.png — https://community.tscircuit.com/media/1534560314337788046

## astrimid — 2026-08-05T13:57:16.222000+00:00

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

## astrimid — 2026-08-05T14:03:35.161000+00:00

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.

## astrimid — 2026-08-05T14:09:19.289000+00:00

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)

## astrimid — 2026-08-05T14:10:39.320000+00:00

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.

## Seve — 2026-08-05T14:19:19.737000+00:00

We should call it an inline netlabel maybe

## Seve — 2026-08-05T14:20:51.015000+00:00

netport etc i dont think that’s inherently more semantically meaningful, wormhole is opinionated

Also curious how kicad designates

## astrimid — 2026-08-05T14:25:58.395000+00:00

If I were to design this from scratch I'd separate concerns
Attachment: image.png — https://community.tscircuit.com/media/1534568151642276051

## astrimid — 2026-08-05T14:26:23.505000+00:00

schematic text with coordinates is probably something circuitjson supports?

## astrimid — 2026-08-05T14:28:18.231000+00:00

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

## astrimid — 2026-08-05T14:37:44.980000+00:00

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

## astrimid — 2026-08-05T14:39:11.525000+00:00

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

## astrimid — 2026-08-05T14:41:10.725000+00:00

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).

## astrimid — 2026-08-05T14:46:02.035000+00:00

KiCAD has offset property of the plain text label
Attachment: image.png — https://community.tscircuit.com/media/1534573200313155667

## astrimid — 2026-08-05T15:01:51.926000+00:00

So the concern levels are:
- authoring
- logical scope and conflict resolution
- placer/routing algorithm
- visual representation
Attachment: 631837807-8ae2acbc-6aca-4e4b-848a-39689dd161b1.png — https://community.tscircuit.com/media/1534577184570736830