I think EDIF pretty much died, no party had a vested interest in making it work and the standard is a bloated mess.
SVG represents a real opportunity to piggy back on the much more dominant force of the interwebs. On Mon, Apr 11, 2011 at 4:18 PM, Steven Michalske <smichal...@gmail.com> wrote: > This is what I see as a benefit. If you go to a vendor's website you > will find one or two EDA footprint and symbol files. But nothing that > was a bell ringer for commonality. It would be nice to have a > universal starting point. > > There is EDIF but I see EDIF as not being so useful, i think they > tried to do too many things, and failed to get them all correct. As > one file format to rule them all. > > I rather see svg symbol format, svg footprint format, and svg.... format. > > Steve > > > On Mon, Apr 11, 2011 at 9:43 PM, Andrew Seddon <and...@seddon.me> wrote: >>> On Sun, 2011-04-10 at 21:55 +0100, Andrew Seddon wrote: >>>> I am exploring the idea of using the Scalable Vector Graphics standard >>>> as an EDA format. >>>> >>>> https://github.com/seddona/svgparts >>>> >>>> Would be interested in your thoughts, there's a little more >>>> explanation on my blog. >>>> >>> >>> What would be the benefit of SVG? >>> >>> Arbitrary symbol sizes? We can scale our current symbols already, but a >>> schematic with very many different symbol sizes will look strange. >>> Indeed limited scaling may be fine, ie. scaling our 900 units long >>> resistor to 800 or 1000 units length -- but pins should always end on a >>> 100 grid multiple. (no that is not really needed to connect nets, but >>> for ordered look.) >>> >>> Currently SVG export should be a trivial task due to cairo -- similar to >>> PS and PDF export. >>> >>> Filled SVG paths are fine, we have it, still without editing support. >>> >>> Do we need other fancy graphics? I do not think so. Schematics design is >>> not really art work. >>> >>> If we really want full SVG, we may consider a "Schematic" Mode for >>> Inkscape. But Inkscape is really a large, complex tool. >>> >>> If it is possible to embedd all the "elelectronics stuff" like >>> attributes, net connection, slots, ... in SVG file, then it may be OK. >>> But the effort -- it is similar to a complete rewrite of gschem. And a >>> rewrite -- again C and guile and GTK? >>> >>> PS: >>> We may consider using inkscapes svg icon set for geda/pcb. Inkspape is >>> GPL, so it should be OK. You may look at files >>> >>> /usr/share/inkscape/icons/icons.svg >>> /usr/share/inkscape/icons/tango_icons.svg >>> >>> Very nice icon set, I intend using it for my plain ruby gschem clone. >>> >>> Best regards, >>> >>> Stefan Salewski >>> >>> >>> >>> >>> _______________________________________________ >>> geda-user mailing list >>> geda-user@moria.seul.org >>> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user >>> >> >> So I think it might help to limit the scope of my intent initially to >> library parts. I'd like to create a truly vendor neutral, widely >> supported EDA library format, and the only way I see to do that is to >> piggy back on a format much larger than anything the EDA industry >> could ever create in isolation. >> >> I'm actually thinking more of a direct convert from the gEDA library >> files so as to maintain design intent, rather than ripping from the >> graphics layer. >> >> >> _______________________________________________ >> geda-user mailing list >> geda-user@moria.seul.org >> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user >> > > > _______________________________________________ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user