EasyEDA Pro support.

[brandon3055]

I initially came here to ask if someone could add EasyEDA Pro support.
But then I realized, Hay! I'm someone, And I know how to program! (in java)
So for anyone who, like me has been experimenting with EasyEDA Pro. Here you go!

EasyEDA Pro to Json

Though I should warn you its very unpolished, the new easy eda format is rather annoying and I did not have much time to work on this. So I got it to the point where it produces a usable json and for now, that is where it will most likely stay for now.

But while I'm here. Not having text is kinda bothering me. So if anyone can give me an example of a working text element that would be great!
I tried using the example listed here https://github.com/openscopeproject/InteractiveHtmlBom/blob/master/DATAFORMAT.md#text
But the result I get is a completely broken ibom that generates without any errors.

[qu1ck]

This looks pretty good but a cursory glance didn't reveal any drastic changes from the normal EasyEDA format. Can you summarize the changes? It may be easier to adapt existing easyeda parser included in ibom to read that too.

Regarding text, the "text" property only works for KiCad. It relies on "font_data" to know how to draw the characters. Since this is KiCad specific, it's not included in the json schema, you should use "svgpath". Here is relevant schema bit:

        "DrawingText": {
            "type": "object",
            "additionalProperties": false,
            "properties": {
                "svgpath": { "type": "string" },
                "thickness": { "type": "number" },
                "ref": { "type": "integer" , "const": 1 },
                "val": { "type": "integer" , "const": 1 }
            },
            "required": [
                "svgpath",
                "thickness"
            ],
            "title": "DrawingText"
        },

[brandon3055]

a cursory glance didn't reveal any drastic changes from the normal EasyEDA format. Can you summarize the changes?

So just taking another look at the old format after spending a while dealing with the new format. I do definitely see similarities. But without digging into the details of the old format I couldn't really tell you how close it is.

One big difference is the source download no longer contains everything you need to construct the board. So instead you need to "save document" which gives you a zip containing several notable files.
The first is a project json. This contains the following lists

• "symbols" (Have not had a chance to investigate those yet)
• "footprints" This is pretty much useless, It just contains basic names for device footprints.
• "devices" This contains a bunch of attributes for each component. The most important of which is a footprint key.

The next notable file is the epcb file. This is what you get when you use the download source option. This contains everything you need to construct the PCB except for the actual components themselves. The component data listed in this file just contains component positions, pin>net mappings and various attributes including a device key.
So to generate the component you need to look up the device in the project.json, get the footprint key, then there will be a dedicated file for that specific footprint in the zip.

you should use "svgpath". Here is relevant schema bit:

Are you saying I would need to convert the text to SVG format? I don't know about the old format but the new format does not seem to include any svg data for the text.

[qu1ck]

So to generate the component you need to look up the device in the project.json, get the footprint key, then there will be a dedicated file for that specific footprint in the zip.

I see, so they are saving a few bytes for no good reason.

Are you saying I would need to convert the text to SVG format? I don't know about the old format but the new format does not seem to include any svg data for the text.

Yes, old format has text in svg format in field 10 of the text entry

InteractiveHtmlBom/InteractiveHtmlBom/ecad/easyeda.py

Line 150 in 31b20f8

svgpath = shape[10]

If it's not there anymore then you'll have to generate it using font and text attributes (size, weight etc). You would need a good library, it's not a trivial task.

[brandon3055]

If it's not there anymore then you'll have to generate it using font and text attributes (size, weight etc). You would need a good library, it's not a trivial task.

Just double-checked but no. This is all you get for text now.

["STRING","e677",0,3,470.4715,-834.644,"BMS","default",59.0551,5.9055,0,0,3,0,0,0,0,0]
["STRING","e2961",0,3,1452.753,-1803.146,"Charger","default",59.0551,5.9055,0,0,3,0,0,0,0,0]
["STRING","e3234",0,3,1037.3995,-2116.1375,"SDA","default",51.1811,5.9055,0,0,3,0,0,0,0,0]
["STRING","e3235",0,3,1037.3995,-2185.035,"SCL","default",51.1811,5.9055,0,0,3,0,0,0,0,0]
["STRING","e3427",0,3,354.33,-2238.1845,"SDA","default",51.1811,5.9055,0,0,3,0,0,0,0,0]

And component designators are similar. They are just added as an attribute on the component.

["COMPONENT","e97",0,1,1007.872,-125.984,90,{"Name":"100R","Unique ID":"gge5"},0]
["ATTR","e97e16",0,"e97",3,973.864,-183.515,"Designator","R1",0,1,"default",45,6,0,0,3,90,0,0,0,0]
["ATTR","e97e98",0,"e97",3,-1228.645,-2242.736,"Device","cd6cb45e51074796b23e2d9695908d37",0,0,"default",67.5,6,0,0,3,90,0,0,0,0]
["PAD_NET","e97","2","$1N2114"]
["PAD_NET","e97","1","$1N5798"]

So that's going to be a lot of fun...

There are also a few other things i need to figure out. Like despite everything else working perfectly a couple components in my test case have their silkscreen offset slightly. And a couple components randomly have their pads rotated 90 degrees. I suspect I'm missing some random offsets and rotations somewhere.
Theres also the issue that the copper areas don't include the cutouts for the traces running through them But I tont really know how that would work with the poly format. anyway. But then again the existing eda converter does not seem to support tracks or copper at all so I guess I cant complain too much xD

Heres my test bom if you want to take a look. https://ss.brandon3055.com/346e8
And the generated json file https://ss.brandon3055.com/6b52f

[qu1ck]

Theres also the issue that the copper areas don't include the cutouts for the traces running through them But I tont really know how that would work with the poly format.

There are 2 ways you can go about it. If you use the array of coordinates then you can imitate holes by fracturing the original polygon. In essence it's adding a 0 pixel wide "channel" or extra 2 edges between some vertex of the "hole" and the outer edge. That's how KiCad does it.
Alternatively you can use svgpath again and just include the hole as extra path alongside the main path. Browser will render it as a hole in the polygon, as long as you adhere to non-zero winding rule.
This has some references:
https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/fill

I could also accept a patch to optionally use the even-odd rule if it makes things easier.

The real issue may be that the actual zone fill is not stored in the project/data, only the outline that the user draws. In that case finding actual shape would mean reimplementing the whole zone fill algorithm, that's why zones are not supported in current parser. (Although I don't dismiss the possibility that the data is there and I just missed it).

But then again the existing eda converter does not seem to support tracks or copper at all so I guess I cant complain too much xD

Current parser supports traces but not zones. Example https://openscopeproject.org/InteractiveHtmlBomDemo/html/2.4G_Telecontrol_Board%20V1.0-PCB.html

[brandon3055]

Current parser supports traces but not zones. Example

Hmm... Ether I'm doing something wrong or EasyEDA did something to break that because this is what I get when I download and convert that example project. https://oshwlab.com/UserSupport/2-4g_telecontrol_board_v1-0
https://ss.brandon3055.com/5b5d3
The example you linked also does not seem to support track/pad nets which somewhat diminishes the usefulness of the tracks.

[qu1ck]

Ether I'm doing something wrong

Probably not passing --include_tracks

And yes, nets are also not supported in easyeda parser.

[brandon3055]

Interesting. Tracks seem to be included by default when generating from the official json format. But even adding --include-tracks does not seem to fix the missing tracks with the default easyeda parser.

[qu1ck]

Tracks seem to be included by default when generating from the official json format.

That's a bug.

But even adding --include-tracks does not seem to fix the missing tracks with the default easyeda parser.

You probably didn't turn on tracks in html. The settings are cached so if you previously had the same page opened and it didn't have tracks they won't appear unless manually turned on.

[brandon3055]

That's a bug.

Good to know. I would probably have been rather confused if one day that bug got fixed and my tracks randomly stopped working xD

You probably didn't turn on tracks in HTML.

That was it.