delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2014/03/04/07:43:00

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Mailer: exmh version 2.8.0 04/21/2012 (debian 1:2.8.0~rc1-2) with nmh-1.5
X-Exmh-Isig-CompType: repl
X-Exmh-Isig-Folder: inbox
From: karl AT aspodata DOT se
To: geda-user AT delorie DOT com
cc: karl AT aspodata DOT se
Subject: Re: [geda-user] Pin length stretch for schematics symbols useful?
In-reply-to: <1393874264.2120.51.camel@AMD64X2.fritz.box>
References: <1391043267 DOT 2058 DOT 19 DOT camel AT AMD64X2 DOT fritz DOT box> <20140303174655 DOT A167B807ABF3 AT turkos DOT aspodata DOT se> <1393874264 DOT 2120 DOT 51 DOT camel AT AMD64X2 DOT fritz DOT box>
Comments: In-reply-to Stefan Salewski <mail AT ssalewski DOT de>
message dated "Mon, 03 Mar 2014 20:17:44 +0100."
Mime-Version: 1.0
Message-Id: <20140304124149.2ECEF807ABF4@turkos.aspodata.se>
Date: Tue, 4 Mar 2014 13:41:46 +0100 (CET)
X-Virus-Scanned: ClamAV using ClamSMTP
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

Stefan Salewski:
> On Mon, 2014-03-03 at 18:46 +0100, karl AT aspodata DOT se wrote:
> > Stefan Salewski:
...
> > > 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.

Isn't that easy enougth for the user to draw the net around the label 
if it sticks out ? I'd say we ignore this case.

> > > 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.

Sometimes there are external requirments. There was one person from 
Russia (I think i was) that wrote that the symbols are to have that
and that dimesions. If so, then you have to think about the resulting 
sizes of the symbols, and that is easier if the schematics is at
scale 1:1 relative the paper printout (or some other fixed and agreed
upon scale, but 1:1 is the one easiest to remember and use).
And for 1:1 the symbols are way to large.

> > 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.

You missed my point, if you have a certain font at a given pointsize, 
e.g. 12 (assuming that an A is 12p heigh), and that that A occupies 12
vertical units in the schematics, then, if you "respect" the font
designer and use the font as it is designed, you have in fact fixed the
vertical units to 1 point, and you should print it out so that the A
becomes 12 points on the paper. And if you don't care about this,
well then you don't care.

...
> > > 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.

Why not an extermal program that does it for you, it doesn't have to be
integrated into gschem. See below.

> > > 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.

I think it would be great if we just have two (european and us style, 
or just one with a 'style = "...", so you could take my schematics, 
change a globel and there you have your kind of resistors) resistor
symbols, which we could be shrunk/stretched/enlarged/rotated/etc.
at will and still be valid an usable. Think of, just one symbol.

If we can solve the pletora of resistor symbols, it would be a great
step forward.

...
> > 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.

I don't really see the point in changing the pin lengths on the fly 
within gschem:

1, it could be done by an external program, generating sets of symbols
   with pin_lenght 200,300,400, etc. and updating the sch file

2, it is easy for the user to "extend" a short pin with a net segment

Yes, it would be an awful lot of sets if you're into this, so why not 
settle for 100 pin length and let the user do the rest?

///

Still I like the idea of symbols that can take parameters.
So we have to find enough arguments for it to make it worthwile.

We already have value (like 100 Ohm), footprint, and such.
You want pin_lengths. I'd say scale/stretch, value/footprint to
be a function (could solve the to92 transistor problem),
parameters passable to subsheets. Any more ?

And visible text autom. adj. when rotating a symbol.

Regards,
/Karl Hammar

-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019