X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	bh=zZx3RwedFyeWxZC9GPyW2xB4XFZ13hQv8wpazSQZ3/g=;
	b=S/UM1hJ91ymH2r5f4JTcYezqnTj+lDrPW5WIaURiIPRBIIn9g/K/PM+Tiohu5diqik
	IoUjxMiQgkyzmHy1IqF/lVhrtEZtO+1ie6/BB17KW8LDgaQP0tMPhOt3viifHPuquZjH
	BsGzLrP1PN1wxtbsJFDZx+IY1ACaKGm+XUJOdB5RFxYPGlMbYyUvVyjhHKzsrBcwD9QY
	cBR4PiUTNH2Sc/VpO4QSfCfc2f7Y3YpHkVDroclq3sCoP8BuMmogHyHaeKkoosO2BelY
	I9HK9O3qgUpp5xmSsSmGNvIzyGQMmbqeg76rxmPfUXcMzaPKPykuFFMfDoDomRluXSGl
	vjyA==
MIME-Version:	1.0
X-Received:	by 10.112.164.35 with SMTP id yn3mr16742405lbb.91.1435707104619;
	Tue, 30 Jun 2015 16:31:44 -0700 (PDT)
In-Reply-To:	<55930E0B.2000200@mcmahill.net>
References:	<CAM2RGhRevQRT_unv2jZs0GYPUtQLy1-BpxhgMfXFY4NseSfFbw AT mail DOT gmail DOT com>
	<55930E0B DOT 2000200 AT mcmahill DOT net>
Date:	Tue, 30 Jun 2015 23:31:44 +0000
Message-ID:	<CAM2RGhQJq1t4aNvHipB3D0n7Vk4qrR=SmLXHGzrbuDpHqnvy=w@mail.gmail.com>
Subject:	Re: [geda-user] Interchange formats
From:	"Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

That was why in the thread that precieded this one I advocated both
projects (kicad, geda) spinning off their libraries for handling file
formats so that each package could call them independently.

brlcad is currently trying to implement all formats with interfaces to
their geometry engine. I really like that approach.

On Tue, Jun 30, 2015 at 9:45 PM, Dan McMahill (dan AT mcmahill DOT net) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
> On 6/10/2015 4:26 PM, Evan Foss (evanfoss AT gmail DOT com) wrote:
>>
>> For those of us who are not as well versed in our history of this
>> subject. I would like to know why so many common EDA formats have
>> failed?
>>
>
> Keeping in mind that this is only my opinion, I think one of the issue is
> that you have two tools.  EDA1 and EDA2.  They may store different data.
> Not just store data differently, but store different data.  Here is an
> example that has come up here recently.  PCB stores rotated footprints as
> opposed to a footprint and a rotation to be applied. Some other tool may
> store the footprint and a rotation and another tool may store a pointer to a
> footprint in a library as opposed to storing a copy of the footprint.
>
> Now suppose you have a format which by some miracle can actually store all
> the data that either program stores.  But what do you do on reading it in?
> You have data that one program wrote out but the other doesn't use.  Or even
> if it does use it for import it may not use it past then.  Using the
> footprint example, maybe PCB could load a footprint from some interchange
> file and rotate per the stored rotation but that is then lost in the
> internal database.  This means a round trip translation (EDA1 to interchange
> to EDA2 to interchange to EDA1) will not produce something identical to
> where you started.
>
> It seems to me then that what is needed for a true standard format is that
> the internal database contents (not the format but what actually is stored
> and manipulated) and how that data is used has to be part of the standard.
> This is much more invasive into program internals than a format which is
> basically output only (like gerber file).  Now you get into a whole turf war
> over whose program gets to be closer to "standard" and also issues over what
> is proprietary or not.
>
> Just my opinion.
>
> -Dan
>
>
>



-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

- Raw text -