On Thu, 2008-01-31 at 08:03 -0500, Ales Hvezda wrote:
> Hi,
> * Part of the above symbol library changes, I might be introducing
> a new step (maybe optional) into the default sch -> pcb (or others)
> design flow. I not going to comment on this too much as I haven't
> formulated the changes sufficiently, but I don't expect this addition
> to cause much hardship.
Can you comment a little..? that is a tantalising one-liner ;) Was this
intended to be the mapping stage where a light symbol gets "heavied"?
e.g. BJT with pins "B", "C" and "E" -> physical pin numbers
-> correct sequence for Spice
Do you see this as a pre-netlist step? I think this fits nearly with the
idea of having some processes which feed data back into the schematic
when they are run.
Do you see this as a mapping "light symbol" + "pinout" -> "attributes"
or "component" -> "light symbol" + "attributes"
> I'll post more details when I'm ready to make the changes.
Did my suggestion of supporting arbitrary "SVG" path strings to form
open and closed paths which can be filled and stroked, make any sense?
It is certainly easy to render these with Cairo, and a subset would
probably be easy for GDK.
The only other things I can think to bear in mind was the idea of
extension blocks which can be skipped when parsing the files?
It might be nice to have all new format sections follow some similar
"preamble" syntax which specifies how many lines should be skipped over
(saved for verbatim replay when saving) if a particular version of
gschem doesn't understand this block. This way, future file-format
additions could be made in a way which doesn't preclude opening / saving
from older versions.
Best wishes,
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
