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=srUsGGnhvnkBmsBknhuBMPCWcE7TE15hi0GllJi3D1A=; b=pFwIr/XttJrj5TzV1mUmqrpvSgEUcpzo9wo4S6oXWNc//JItPHscVjg88jHHy04WiM x+GdE2CGPFM2aKsuUQpZrKf0G0c3+wcyIlMOXDMXIxGQ0GNpnur+4e9K4ofMuDMUcAJD 4Z3Spdiu8GB8DhzaTqS9lvA0c9b6LYQe0QdjhYap3PE0pZNODTjNRgh9DACFjbYMAQEK gnJ4sq5wrE6oa33QvjBCy6toZroBYNrokwDNtQ7LVHyIYowKF8ry9C7f9CrlGBYUUJuY 6LmlH8EZE4giyRBdTmqMiHVWW9giayBwfHpOfyC8zZPQEDeNH0UKcbmI0+NfLSgWsSKT wROA== MIME-Version: 1.0 X-Received: by 10.50.225.35 with SMTP id rh3mr1035553igc.29.1440491476292; Tue, 25 Aug 2015 01:31:16 -0700 (PDT) In-Reply-To: References: <20150824223846 DOT 0ba61ba7 AT jive DOT levalinux DOT org> <55DBA2B7 DOT 1080501 AT ecosensory DOT com> Date: Tue, 25 Aug 2015 10:31:16 +0200 Message-ID: Subject: Re: [geda-user] pcb file format From: "Levente (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com]" To: gEDA User Mailing List Content-Type: multipart/alternative; boundary=001a1132f214bf2033051e1e8e92 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 Precedence: bulk --001a1132f214bf2033051e1e8e92 Content-Type: text/plain; charset=UTF-8 As I stated, text is not yet supported, but will be added to the specification. vias are specified as padstacks. You can define any pad on any layer. bezier curves is not on my todo list. However, we can define a bezier curve object, and add vertexes. :-) Layer structure is going to be defined. Rotation is defined in the relation table. Lev On Tue, Aug 25, 2015 at 9:15 AM, Erich Heinzle (a1039181 AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > The new kicad s-file format is basically a tree structure using > parantheses to demarcate the nodes. It is easily parsed by simple > utilities, and is quite human readable. > > We could do worse than to duplicate their format. We also seamlessly get > the benefit of kicad footprint creation tools and footprint libraries. > > Perhaps we should list the things a new file format should ideally > support... it seems pointless to implement a new format unless it > significantly extends the usefulness of PCB.... these are in no particular > order, but are features that are hard to do with the current format.... a > few things that come to mind include: > > text in footprints (kicad supports hidden and visible flags) +/- font > selection > vias between layers > bezier curves (these are already supported by gschem's symbol format) > obround pad/pin definitions > a standard range of default layers - again, we could do worse than to copy > kicad's 32 layer structure. > slots, non plated and plated > perhaps a rotation value for an element in a layout > > Just some thoughts. > > Erich. > > > > On Tue, Aug 25, 2015 at 8:33 AM, John Griessen > wrote: > >> On 08/24/2015 03:38 PM, Lev (leventelist AT gmail DOT com) [via >> geda-user AT delorie DOT com] wrote: >> >>> Here I propose the file format of the next generation of PCB. The file >>> is an >>> sqlite database. >>> >> >> I like it. And go ahead and use Fossil, the DVCS by the same authors as >> sqlite >> for the project. >> >> "and you can now start throwing eggs, >> potatoes, tomatoes." >> >> Oh, maybe it is not super compact. How different in file size is it? >> sqlite probably has easy to use compression for the file based DB... >> >> John, not throwing anything >> > > --001a1132f214bf2033051e1e8e92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As I stated, text is not yet supp= orted, but will be added to the specification.

vias are specif= ied as padstacks. You can define any pad on any layer.
bezier curv= es is not on my todo list. However, we can define a bezier curve object, an= d add vertexes. :-)
Layer structure is going to be defined.
Rotation is defined in the relation table.

Lev

On Tue, Aug 25, 2015= at 9:15 AM, Erich Heinzle (a1039181@= gmail.com) [via geda-user AT delo= rie.com] <geda-user AT delorie DOT com> wrote:
<= div>The new kicad s-file format is basically a tree structure using paranth= eses to demarcate the nodes. It is easily parsed by simple utilities, and i= s quite human readable.

We could do worse than to duplicate th= eir format. We also seamlessly get the benefit of kicad footprint creation = tools and footprint libraries.

Perhaps we should list the thin= gs a new file format should ideally support... it seems pointless to implem= ent a new format=20 unless it significantly extends the usefulness of PCB.... these are in no p= articular order, but are features that are hard to do=20 with the current format.... a few things that come to mind include:

=
text in footprints (kicad supports hidden and visible flags) +/- font= selection
vias between layers
bezier curves (these are a= lready supported by gschem's symbol format)
obround pad/pin de= finitions
a standard range of default layers - again, we could do = worse than to copy kicad's 32 layer structure.
slots, non plat= ed and plated
perhaps a rotation value for an element in a layout

Just some thoughts.

Erich.



On Tue, Aug 25, 2015 at 8:33 AM, John Griessen <john AT ecose= nsory.com> wrote:
On= 08/24/2015 03:38 PM, Lev (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
Here I propose the file format of the next generation of PCB. The file is a= n
sqlite database.

 I like it.=C2=A0 And go ahead and use Fossil, the DVCS by the same authors = as sqlite
for the project.

"and you can now start throwing eggs,
potatoes, tomatoes."

 Oh, maybe it is not super compact.=C2=A0 How different in file size is it?<= br> sqlite probably has easy to use compression for the file based DB...

John, not throwing anything


--001a1132f214bf2033051e1e8e92--