Mail Archives: geda-user/2014/03/03/14:22:51
On Mon, 2014-03-03 at 18:46 +0100, karl AT aspodata DOT se wrote:
> 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.
Generally we position pin number and pin label above or below the pin.
Or we may put a textual label there. So we need some room.
>
> > 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.
If I remember correctly a few people said that all symbols are too large
-- at least one person was going to make a new smaller symbol set. That
makes not much sense. Relation of course is important, but not absolute
size.
>
> 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.
For font size and type my peted gschem clone offers much more freedom,
that is an easy task with pango.
>
> 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.
Scaling of symbols may be an interesting idea? But my general feeling
is, that i.e. the body of all resistors should have the same size (OK,
maybe with very few exceptions.) And of course scaling has the problem,
that pin endpoints should rest on the grid for a clean look.
>
> 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.
>
For line width my peted should also offer much better support -- scaling
and clipping. I was never happy with linewidth 0 of most gschem symbols.
> > 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.
Better wording: Enable default pin length = 300 for all symbols, special
symbols can have an "pin_length=200" attribute.
>
> > 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.
Well, peted may offer an "pin_length_offset=200" attribute, which gschem
ignores. So there will be gaps of 200 for this case when the schematic
is drawn with peted and then loaded into gschen. True.
That was the reason why I wrote that post -- it was my hope that geda
developers would like such a feature -- so I could simple copy it.
>
> > 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 ?
I think that is really not easy for the general case. For OpAmps and
other large parts 90 degree rotation makes not much sense -- 180 degree
rotation and mirroring is much easier for text repositioning. For the
small parts like resistors, we may offer rotated version with good
default text positions, i.e. available by context menu with right mouse
button. Generally it may be good to offer variants when user clicks left
mouse button over an symbol, i.e to offer OpAmp with +- inputs
exchanged.
>
> > 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 ?
First goal is on the fly modification like "pin_length=300" or
"pin_length_offset=200" for trivial variants. Next trivial step may be a
"pin wizard", i.e generate 8 left side pins numbered 16 to 24. So user
only has to rearrange the pins, draw some graphic and has a symbol.
>
> 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 ?
My basic idea was simple to modify symbols on the fly -- for pin-length
that is easy and useful. Other stuff needs thinking, and of course I
would like to be fully compatible with gschem. Only nicer look, easier
user interface, simpler and shorter code.
Best regards,
Stefan Salewski
- Raw text -