Hi, There happens to be a newer version (1998) of the IDF specification:
http://www.simplifiedsolutionsinc.com/images/idf_v40_spec.pdf Kind regards, Bert Timmerman > -----Original Message----- > From: geda-user-boun...@moria.seul.org > [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Bert Timmerman > Sent: Sunday, September 05, 2010 11:13 AM > To: 'gEDA user mailing list' > Subject: Re: gEDA-user: Functional blocks and PCB format changes > > Hi Rick, > > > -----Original Message----- > > From: geda-user-boun...@moria.seul.org > > [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Rick Collins > > Sent: Sunday, September 05, 2010 12:38 AM > > To: gEDA user mailing list > > Subject: Re: gEDA-user: Functional blocks and PCB format changes > > > > At 11:49 AM 9/4/2010, you wrote: > > >On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote: > > > > > > > > Don't hold back, tell us how you really feel! > > > > > > > > The spec is large because it addresses a wide range of design > > > > aspects, which is one of the great reasons for using > it, one file > > > > for the entire design, schematic, layout, mechanical, etc, even > > > > board lay up. So the compatibility issue is moot > because any one > > > > app only needs to deal with the portion that applies to > it. Just > > > > don't muck with the other parts. > > > > > > > > The "heavy" issue is a red herring (are you planning on > > hosting this > > > > on a cell phone maybe?) No PCB file format is going to > > be easy for > > > > humans to read. Bandwidth? Back to the MCU in the > cell phone I > > > > guess. "Ugly", now there is a great technical argument. > > > > > > > > But I suppose it is better to re-invent the wheel. There is no > > > > reason to try to foster any sort of compatibility in > file formats > > > > between all the different CAD tools. There are always > conversion > > > > programs to be written, no? > > > > > > > > > >This is not an emotional argument, but a technical one, and > > the choice > > >is not between XML and reinventing the wheel. (Sadly, my Lisp > > >suggestion has been shot down - by better arguments than > > popularity, I > > >might add. ;) There are other formats to consider, and yes, > > inventing > > >one might be an option. > > > > > >How do you know PCB won't ever run on cell phones, or over a slow > > >network link, or on an embedded device or network PC or overtaxed > > >virtual machine? How do you know we won't one day need to > work with > > >1000-layer boards when suddenly it /does/ matter how heavy > the file > > >format is? > > > > So are you suggesting that we should, at this time, plan > for running > > PCB on a cell phone? Do you want to design PCB to work on > overtaxed > > virtual machines, if so, I expect there will be a lot more > important > > things to optimize than the file format which only impacts the > > performance when reading or saving the file. If we need to > work with > > 1000 layer boards, I expect we would have computers which > would be not > > at all burdened by XML file formats. > > > > I'm trying to be realistic about the requirements. I think > that the > > 2x or 3x factor of file size of using something like XML > would be lost > > in the noise. The advantages of working with an industry standard > > file format could be very large. > > Of course as you or someone pointed out, IPC-2511B is not a well > > established format. But to my knowledge it is the only one > that spans > > most if not all aspects of circuit board manufacturing. It > seems like > > a great idea to work with something this useful and I am > pretty sure > > that concerns with using it can be ironed out. > > > > > > >Unless you want feature-parity with other CAD programs, it is > > >impossible to have file-format-parity. So no matter what, > conversion > > >programs will have to be written. Creating similar file > > formats won't > > >help anything, other than to limit our own format, and potentially > > >cause problems if PCB and another CAD program are able to open (and > > >corrupt) each other's files. > > > > I don't agree that a common file format has to be > restrictive. If the > > file format is flexible enough, the program won't be limited. > > Everything doesn't have to be included from the start. I > don't know > > if IPC-2511B is flexible enough for PCB and future ideas > for PCB, but > > using XML I expect it can be expanded easily. I don't think anyone > > here has really looked hard at it. It may well be extensible. I > > don't know. But I would like to at least consider it and > not toss it > > away without giving it a chance. > > > > Rick > > > > > > IMHO, the "problem" with XML lies not in the bloat, even a > factor 10 larger would be acceptable, it's the <$TAGS> that > have to be identical across all applications to have a > "truly" exchangable XML file. > > I think that for an exchangable format for schematic capture, > pcb layout __and__ 3D mechanical CAD stuff the "problem" is > waaay to big to grasp in a forthnight and DIY. > > And there happens to be a standard of sorts which does just > that, named IDF, some of the large commercial CAD vendors > play this game already. > > In this playfield design files with 1MB < size < 10MB is not > that uncommon these days. > > Welcome in "Utopia" mate ;-) > > Have a look at: > > http://www.simplifiedsolutionsinc.com/images/idf_v40_overview.pdf > > http://www.protel.com/files/training/Module%2020%20-%203D%20Me > chanical%20CAD > .pdf > > http://www.simplifiedsolutionsinc.com/images/idf_v30_spec.pdf > > Happy reading ;-) > > Kind regards, > > Bert Timmerman > > > > _______________________________________________ > 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