Mail Archives: geda-user/2014/03/03/12:48:01
Stefan Salewski:
> Is an optional attribute for symbols of the form
>
> "pin_length_offset=200"
>
> useful? My intend is, that we can have one symbol which can be used with
> different pin length. Offset can be negative, so that we have shorter
> pins, which can be useful when space is limited.
>
> Of course, pins are not really special, so we can extend each short pin
> simple with a net.
> But my feeling was and is still that different pin
> lengths are useful, i.e for labels.
I don't understand you here.
> And I can remember that people have
> argued that gEDA symbols are too large -- at least one was going to make
> a smaller set. Of course that is nonsense, because we can simple use
> larger title blocks, so symbols are scaled down for printout.
I don't think it is nonsense, the problem is that sometimes a symbol is
to big in relation to another symbol, e.g. a damping resistor attached
to a mcu port.
Also fonts usually comes in different fatness at diffrent point sizes.
I don't know about the geda font, but fonts are usually not god at a
pointsize not equal the designsize. Perhaps the geda fonts aren't
optimized like that.
Also, in your thinking you need title blocks of different sizes, which
actually points to the same problem. In this case an optional
"scale_this_symbol = 5" could help.
When you have a few schematics on paper, it is good to have all nets
on all papers to have the same line width e.g. 0.25mm, and so on...
If you scale your schematics at will, it would break that consistency.
> Problem is still, that people may populate schematics very dense --
> I did it myself.
It helps to get an overview (you might need that in the first few
iterations of a schematic).
> If we enable "pin_length_offset=300" for all symbols of a
> schematic that problem is solved, space is forced.
I don't like forced on solutions.
> Implementation should be simple, just extend all pins of an symbol by
> the given offset, extend that side which is used to connect nets.
Well that is the simple part, but then the user might end up connecting
or redacting the missing distance -- for all pins.
> PS: Indeed I was thinking about how text attributes (labels, numbers,
> refdes) should behave in a perfect world when symbols are rotated, but
> that is of course not a trivial problem.
That would be a wery useful feature to implement. I think it would
require a few hints or heuristics to make it work. Any ideas ?
> So I remembered the pin_length_offset -- hope that at least that is trivial.
I like the idea of on the fly change of symbols so you don't need
different symbols of the same kind, where a "simple" "force_pin_length
= 50", "pin_distance = 200" or "scale_symbol = 0.25" could suffice.
That would point in the direction of gschem to contain an embedded
symbolgenerator och to that effect gschem would need a generator
language. Is that your goal ?
If so, one should perhaps first construct a standalone generator that
is sufficiently capable and popular so people stops doing their
symbols --- they'll start writing generator inputs instead. Any ideas ?
Regards,
/Karl Hammar
-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
- Raw text -