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=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=oocZe3UxIqGj94ZkFwY/1gp3dNqFQ0902HL/RDr4jz4=; b=0h9DuFYM8/IaXDDc2lUJSBLPg85TkjAvFxEQ3C+IcbJFIkjzfqNvNb3Ms/J5vm0C44 1kdRS+H8LRYd2zihme04TecxCI3cDWOAKhSD9kAhxHJAdpb/5zjJXW3UXKcmzfg4sZ9/ LrO1YQjNSzZYrpDgXjb/2Bw0i8pA7dpEMMH/7MvxnD89djo/deFOoRlUdtCvzhkb9/fj oCLUDpoW1+LsCgJL/8QvMuqG2DRVd0pHFst929IBwqRSpt1Ugew2/2BAUqGCyVoUGFqL ftL04sJj8laz6kBLDAN2w1baVUFFwJ37yyTm9ZZV+5r6ijOZlZWmi7mIUevf+pg9ttzE E2FA== MIME-Version: 1.0 X-Received: by 10.60.59.101 with SMTP id y5mr39542397oeq.61.1452082954125; Wed, 06 Jan 2016 04:22:34 -0800 (PST) In-Reply-To: References: <1512221837 DOT AA25291 AT ivan DOT Harhan DOT ORG> <20160105182120 DOT 3237F809D79B AT turkos DOT aspodata DOT se> <8E0210CD-0694-4717-A7B1-3224E39691DA AT sbcglobal DOT net> Date: Wed, 6 Jan 2016 12:22:33 +0000 Message-ID: Subject: Re: [geda-user] A fileformat library From: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" To: gEDA User Mailing List Content-Type: multipart/alternative; boundary=089e0149d164aa52700528a96863 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 --089e0149d164aa52700528a96863 Content-Type: text/plain; charset=UTF-8 On 6 Jan 2016 11:50, wrote: > > I think this is a common misunderstanding. The reason PCB doesn't support burried/blind via is like 5% file format and 95% all-internal-code-in-pcb. (The 5-95 split is an educated guess, not a fact, but I believe it's not far from reality). The 95% includes everything from find.c and DRC to export HIDs and GUI HIDs. > > If we want blind/burried vias, we'll need to find how it is to be represented in a save file eventually, but the bulk of the work won't be around that part. Indeed, although it realistically isn't actally that huge a task from the data point of view. The most obvious missing thing I can see, is a physical layer stack model. Pcb layers don't explicitly map 1-1 to physical layers - and at the very least, we need to inforce a defined ordering of layer groups, before a to-from layer group notion makes sense. (I sort of did this in the 3D branch, but it needs to be more explicit). What may be a little harder, is updating the gui and renders to give a sensible interface for creating and editing this type of design feature. Since it blocks the 3D stuff, I'm taking an interest here (regarding more explicit board construction info / layer stack description), and I have plans to address this. I will also put my hand up to do the blind / buried vias, at least the back end part, and possibly a basic gui implementation in one HID - unless anyone is desperate to beat me to it! Peter --089e0149d164aa52700528a96863 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 6 Jan 2016 11:50, <gedau AT igor2= .repo.hu> wrote:
>

> I think this is a common misunderstanding. The reason P= CB doesn't support burried/blind via is like 5% file format and 95% all= -internal-code-in-pcb. (The 5-95 split is an educated guess, not a fact, bu= t I believe it's not far from reality). The 95% includes everything fro= m find.c and DRC to export HIDs and GUI HIDs.
>
> If we want blind/burried vias, we'll need to find how it is to be = represented in a save file eventually, but the bulk of the work won't b= e around that part.

Indeed, although it realistically isn't actally that hug= e a task from the data point of view. The most obvious missing thing I can = see, is a physical layer stack model. Pcb layers don't explicitly map 1= -1 to physical layers - and at the very least, we need to inforce a defined= ordering of layer groups, before a to-from layer group notion makes sense.= (I sort of did this in the 3D branch, but it needs to be more explicit).

What may be a little harder, is updating the gui and renders= to give a sensible interface for creating and editing this type of design = feature.

Since it blocks the 3D stuff, I'm taking an interest her= e (regarding more explicit board construction info / layer stack descriptio= n), and I have plans to address this.

I will also put my hand up to do the blind / buried vias, at= least the back end part, and possibly a basic gui implementation in one HI= D - unless anyone is desperate to beat me to it!

Peter

--089e0149d164aa52700528a96863--