Seve - @Abse bitmap probing

Standard missing prop warning

ok on which repo should this warning be , also we are using chips for the imported pushbuttons how can we detect if it's a pushbutton ?

circuit json to gerber does not have gerber rasterization to pixels

Svg to png is fine

Core

Pushbuttons should be imported with the name <pushbutton /> or <switch /> when imported from jlcpcb

If a user specifies the name as PB* or SW* but they use a chip- we should warn about reference designator convention (which needs a new circuit JSON warning)

ok I'm lost haha , should I start with easyeda converter to make sure we use pushbutton or switch componet when importing ?

Yea i mean all these things have to come together

You can start anywhere but the methodology is just to warn the user to add precision until we fully understand how the chip is configured

Its like in typescript- you can keep adding types until you fully pass typecheck or you can ignore them

ok for the svg to png should we use @resvg/resvg-js ?

Use @tscircuit/image-utils if possible? If not yea

I think image utils handles the browser/node issues

Because you have to use wasm sometimes for it to run in browser

We should have an svg to png in image utils for sure that manages all the annoying compat issues

@tscircuit/image-utils don't do svg to png on it's own

Yea maybe expose it from image utils

ok

It might be easier to use resvg just to get things moving

we should do @tscircuit/image-utils/resvg

I can start it

Yea its not very dangerous because all the exports have their own folder

So i dont see how you could break things

Idk also

Bundling can be weird with wasm

your scaring me haha , is it a vital dep that can break things ?

So you might want to use the wasm version only

It cant break things because you have a subdir

@tscircuit/image-utils/resvg

But like, resvg-js doesnt work in browsers

so we need a good repro and prove that we fixed it

Maybe just focus on the gerber stuff haha

Yea

Rushabh did some work on this cc <@452450065941004289>

ok so I will go with resvg for this pr and we can make it cleaner with time ig ?

Yea

Otherwise you would need to use playwright and check bundle sizes which is annoying

I think resvg is great but i think we could probably create a slower clone of it that is vanilla js

That works for our subset of svgs

Eventually

<@757706909351411845> https://github.com/tscircuit/check-shorts/pull/5 I used resvg and tried to split code into smaller files

also `<switch /> ` doesn’t take `pinLabels` the way `<chip /> ` and `<pushbutton />` do

should we add it ? to make the import possible with <switch / > ?

Yea for sure we should add it

pinLabels on everything mosy

still messing the <switch / > with pinLabels will add then tag you for review

https://github.com/tscircuit/easyeda-converter/pull/402

<@757706909351411845> `source_simple_switch` is extending `source_component_base` , should we add pin labels there ?

pinLabels is a props thing

omg haha I'm lost

```tsx export interface CommonComponentProps<PinLabel extends string = string> extends CommonLayoutProps { key?: any name: string displayName?: string datasheetUrl?: string pinAttributes?: Record<PinLabel, PinAttributeMap> supplierPartNumbers?: SupplierPartNumbers cadModel?: CadModelProp kicadFootprintMetadata?: KicadFootprintMetadata kicadSymbolMetadata?: KicadSymbolMetadata children?: any symbolName?: string doNotPlace?: boolean /** * Allows the PCB component to hang off the board (e.g. for USB ports or displays) */ allowOffBoard?: boolean /** * Does this component take up all the space within its bounds on a layer. This is generally true * except for when separated pin headers are being represented by a single component (in which case, * chips can be placed between the pin headers) or for tall modules where chips fit underneath. */ obstructsWithinBounds?: boolean /** * Whether to show this component's CAD model as translucent in the 3D viewer. */ showAsTranslucentModel?: boolean mfn?: string manufacturerPartNumber?: string /** * This component will be drawn as part of this section e.g. "Power" */ schSectionName?: string /** * This component will be drawn as part of this sheet e.g. "Main" */ schSheetName?: string } ```

we don't want pinlables to be added to CommonComponentProps ?

Probably

probably no ?

so we only add it to switch props ?

Probably yes but idk

I think so

Idk why we havent

ok will add it to CommonComponentProps

<@757706909351411845> can we merge this ?

https://github.com/tscircuit/check-shorts/pull/5

Yea go nuts

Ill do a more comprehensive review of the repo at some point but as long as there are readable analysis pngs ur probably good

sg

<@757706909351411845> We’re adding pinLabels to common component props so <switch /> can use the same pin label map style as <chip />. I moved the shared pin label type/parser out of chip.ts into common code, then had both chip and common props use it. Chip keeps the same exports, so nothing should break. pin-header stays special because it also supports array labels like ["VCC", "GND"].

should all support array labels like ["VCC", "GND"] ? or just keep it for pin headers only

kk

uhh

so one thing i'd be cautious about is certain elements have more precise pinLabels

that might be why it's separated

we want to make sure we're still able to do type autocomplete i think

i like the idea of introducing a side1/side2 alias for pushbuttons 🤔

i.e. pinLabels={{ side1: "..." }} might be type safe for some types of elements

i can't remember

i mean fwiw you could just quickly add pinLabels to switch or pushbutton if there's a type issue and we can just figure out the design later

https://github.com/tscircuit/props/pull/717

<@757706909351411845> https://github.com/tscircuit/core/pull/2580

<@757706909351411845> what is the concern with the PR?

How do we map pin numbers to the symbol ports

I'm not sure, I can check tomorrow? I went to bed, although I thought this was handled before in core I just updated the package and made the test

Yea its ok- just preparing for a future issue

So what should I change to make this acceptable to merge?

I couldn't sleep thinking about this 🤣

It’s OK to merge, but we’re probably gonna have to change it and we should keep that in mind

We need to make sure that when the JC footprints come in that we’re able to match them so that the symbol is correct

The schematic symbol

<@757706909351411845> eval is not updated in tscircuit https://github.com/tscircuit/tscircuit

hmm

i thought we were creating auto-merge prs for these changes

i just added tscircuitbot being able to bypass that rule- but this repo isn't set up like our other repos that require a pull request

CC <@809856037376491570>

<@757706909351411845> <@809856037376491570> https://github.com/tscircuit/tscircuit.com/pull/3831

<@757706909351411845> https://github.com/tscircuit/easyeda-converter/pull/405

one of the gameboy diodes had (_NEG) we need this to only let a-z 0-9 and + - only