Mail Archives: geda-user/2018/02/09/12:12:22
On Fri, 9 Feb 2018, karl AT aspodata DOT se wrote:
> Igor2:
> ...
>> 2. if you just 'save', it should save in the same original format you
>> loaded from (or last saved in)
> ...
>
> Not really true, you seems to have invented a "floater" flag
> which pcb doesn't understand, and what happened to the "lock" flag ?
It is true, minus the temporary bugs. Bugs can be fixed only when
reported.
We do a best effort save to any alien format, including .pcb. If you find
a bug, just repot it and it will get fixed. At the moment not too many
pcb-rnd users use the mainline file format, as it can't express most of
the "new" features they use daily. So testing the .pcb path is welcome.
Yes, we introduced a lot of new features, but that has nothing to do
with the goal of being able to save in alien file formats. A "load .pcb
file, save as lihata, load lihata, save as .pcb" should always work and
shouldget back the original .pcb file without much data loss. If that
doesn't happen with your file, please do report (preferrably with
minimal test case attached).
>
> $ pcb-rnd -V
> pcb-rnd version 1.2.7 rev svn r14602
> $ cp original.pcb tt.pcb
> $ pcb-rnd -gui lesstif tt.pcb
> adding a line
> File->save layout
>
> $ diff tt.pcb original.pcb
>
> 880c871
> < Element["" "apem_3mek_sc.fp" "M2" "unknown" 92.75mm 71.25mm -18.75mm -15.5mm 0 100 "floater"]
> ---
>> Element["lock" "apem_3mek_sc.fp" "M2" "unknown" 92.7500mm 71.2500mm -18.7500mm -15.5000mm 0 100 ""]
> 882,893c873,881
> < Attribute("footprint" "apem_3mek_sc.fp")
> < Attribute("refdes" "M2")
> < Attribute("value" "unknown")
>
> $ pcb tt.pcb
> ERROR parsing file 'tt.pcb'
> line: 844
> description: 'Unknown flag: "floater" ignored'
> ERROR parsing file 'tt.pcb'
> line: 880
> description: 'Unknown flag: "floater" ignored'
> ERROR parsing file 'tt.pcb'
> line: 897
> description: 'Unknown flag: "floater" ignored'
Thanks for reporting, worked around in r14603.
(The real fix would be to upgrade pcb with the flag compat patch, back
from 2013 - but I gave up on trying to get it applied back in 2015)
> pcb: rtree.c:1054: r_insert_entry: Assertion `which->X1 <= which->X2' failed.
> Aborted
Fixed a negative coord in the padstack -> old-pad converter in r14604.
It seems mainline doesn't like negative pad widths (pcb-rnd had no
problem with them and rendered things as numerically expected).
However, the assert is a bug in pcb - it should not assert even on invalid
input. If it doesn't like negative coords in some fields, it should
probably check for those and give a meaningful error message.
If you find further bugs in pcb-rnd's io_pcb, please make bugreports,
preferrably with a minimal test case attached. Please remember that we are
still in the middle of the data model switchover, so this is exactly when
these bugs should be introduced, should be found & reported and get fixed,
so that the next release in late March would be stable.
Regards,
Igor2
- Raw text -