X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
Message-ID:	<52232D2A.2010106@xs4all.nl>
Date:	Sun, 01 Sep 2013 14:03:54 +0200
From:	Bert Timmerman <bert DOT timmerman AT xs4all DOT nl>
User-Agent:	Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.19) Gecko/20110429 Fedora/2.0.14-1.fc13 SeaMonkey/2.0.14
MIME-Version:	1.0
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] PCB file format - compatibility suggestion
References:	<alpine DOT DEB DOT 2 DOT 00 DOT 1309010843540 DOT 11551 AT igor2priv>
In-Reply-To:	<alpine.DEB.2.00.1309010843540.11551@igor2priv>
X-Virus-Scanned:	by XS4ALL Virus Scanner
Reply-To:	geda-user AT delorie DOT com

gedau AT igor2 DOT repo DOT hu wrote:
> Hello all,
>
> I've started a local branch/fork/whatever of PCB to add a few features 
> I need daily. These features required adding new element and pin/pad 
> flags. Mainstream PCB does not understand these flags, and that is 
> expected. However, loading&saving the design in mainstream PCB will 
> remove those flags - which is (imo) much less expected.
>
> The reason is not the file format, but the way PCB operates on the 
> file: it tries to load and parse everything and store in a convenient 
> native represetnation in memory and render the text version from that 
> upon save.
>
> I still remember the long threads about the PCB file format vs. 
> xml/json; one of the potential reasons for such a format would be that 
> it might be easier to keep unknown subtrees intact. However, I am 
> _not_ suggesting changing the format.
>
> Instead, a partial solution, a minor hack would be to upgrade the 
> string<->flags converter. The flag format is a comma separated string, 
> the converter could easily save any unrecognized segment as string, in 
> a linked list in the flags structure. On save, the list could be 
> appended to the flags string rendered the usual way. This may change 
> the order of flags in a round trip but would not change the actual 
> flag values.
>
> Rationale: some feature patches may require changes in the file 
> format, but very often this is limited to new element/pin/pad flags. 
> Such a feature would allow file format compatibility among 
> branches/forks/flavors of PCB.
>
> Regards,
>
> Tibor Palinkas
Hi,

AFAICT you can add "attributes" to pcb files for (specific) meta data 
beyond of what the pcb application understands and can handle.

With a specific plug in or exporter one can handle this meta data.

BTW, I never dug very deep in how "attributes" are implemented inside 
the pcb codebase.

Kind regards,

Bert Timmerman.

- Raw text -