Mail Archives: geda-user/2016/01/06/06:44:34
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-736034488-1452080788=:9035
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
On Wed, 6 Jan 2016, Stephan B=C3=B6ttcher wrote:
>
> "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]"
> <geda-user AT delorie DOT com> writes:
>
>> The big potential down-side to *extending* via (not just supporting)
>> YAML/JSON/SQL, relative to extending the existing format is that tools
>> that do partial parse have no chance to continue working unmodified. Th=
is
>> sounds worse than it is though.
>
> Those "tools that do partial parse" are awk and sed, and small scripts,
> typed day to day fresh on the commandline, or embedded in Makefiles.
> Those will adapt to whatever extensions are added to the file
> format. But they must not become non-awk-parsable.
>
> Those "tools that do partial parse" are required to solve problems, or
> provide features, that the primary tools do not provide, yet, but which
> need solutions now.
>
> E.g., rigid-flex boards. One of those is right now driving around on
> Mars, designed with gaf and pcb. Other boards in the same box have
> complex shapes, with lots of Arcs. Those where designed with gnumeric,
> which yielded a pcb file fragments that were cut&paste into the layout
> file. Like this one:
> http://www.ieap.uni-kiel.de/et/people/stephan/msl/eda/RADE/RADE-silk.png
Nice!
Btw, in pcb-rnd my policy is to keep formats awk parsable. If mainline=20
switches to sql or other binaries, pcb-rnd will become incompatible=20
(or compatible with external converters only) instead of implementing it.
>
> This kind of accessibility to the file format is what keeps me using gaf
> and pcb. The tools will never do all what I need natively, when I need
> it.
+1
<snip>
> Does pcb scripting support drawing a line between to points? There may
> be a lot that can be done with scripts in PCB. But it is certainly not
> discoverable, and from what I read from the manual, once I found it,
> it is not complete. You cannot :ExecuteFile() a script into an empty
> layout and get a finshed board, can you? If you could, that script
> would be a file format for layouts. Next, I'd ask for an export hid to
> write such scripts.
I am not sure about pcb's action script. pcb-rnd's gpmi plugin has a=20
package that lets scripts (awk, perl, scheme, etc.) access design data in=
=20
memory. Scripts can search/list objects, delete/move/change existing=20
objects or create new objects (arc, via and line for now). This can also=20
work in the way you described: draw something from scratch on an empty=20
design.
The other direction, converting an existing design into a set of draw=20
commands in one-of-the-10-scripting-languages doesn't exist. It wouldn't=20
be veryhard to make it, but I am reluctant about moving design data from a=
=20
pure data format to a script format.
>
> If the current file format is extended by adding layer fields to all
> objects, those object stanzas become script commands:
>
> Line["signal2" 119.6929mm 101.0041mm 4757.60mil 102.9959mm 0.2500mm 0.500=
0mm "clearline"]
>
> Add layer fields to Via to support blind/burried vias.
>
> The layer fields in the objects inside an Element support: text on silk,
> boards with more than two outer layers, ...
>
> This might need to be complemeted with another syntax/indirection level
> for specifying layers.
>
> "flextop", "flextop:silk", "flextop:mask", "flextop:paste", "flextop:out=
line"
>
> The data model becomes more othogonal, no restrictions what can be drawn =
where.
>
> Step 1. teach PCB to read this format within scripts. Throw Errors when
> something is drawn where the current data model does not allow.
>
> Step 1b: allow this format in layout files.
>
> Step 2. teach PCB to write this format.
>
> Steps 3...: change the internal data model to support more and more of ca=
ses.
I think this is a common misunderstanding. The reason PCB doesn't support=
=20
burried/blind via is like 5% file format and 95% all-internal-code-in-pcb.=
=20
(The 5-95 split is an educated guess, not a fact, but I believe it's not=20
far from reality). The 95% includes everything from find.c and DRC to=20
export HIDs and GUI HIDs.
If we want blind/burried vias, we'll need to find how it is to be=20
represented in a save file eventually, but the bulk of the work won't be=20
around that part.
Regards,
Igor2
--0-736034488-1452080788=:9035--
- Raw text -