Mail Archives: geda-help/2021/03/02/09:05:26
Roland Lutz:
> On Fri, 26 Feb 2021, karl AT aspodata DOT se [via geda-help AT delorie DOT com] wrote:
> > if I want to use *schem to make schematics with currents and voltages
> > indicated with lines and arrows, for inclusion into some doc. or paper
>
> what you want to be able to control here is *join* style, not cap style.
Partially true.
If I was to use multiple lines instead of one "path", it would be "cap"
style.
So, what would happen if we would like to replace a closed path of
singly "line" (with a suitable cap style) with a "path" ending with a
"z" to close it ?
Is this the message "we don't really support paths since we cannot
control joins" we want to send to users ?
For a closed path, there is no line ends, so there is no use of the
cap style, so why not overload it, it means in effect the same thing
as the cap style for multiple lines (except that two lines meeting in
the same point with a cap style "square" or "butt" will look ugly).
And, do we really need a join style to be differnt from the cap style ?
So why not equate:
cap vs. join style
butt bevel
square miter
round round
There are actually not much to gain by not doing the equivalence, unless
you are willing to add something that controls the join style.
> There is no field for this in the schematic file format, and so far, I
> considered keeping the file format stable to be more important than
> introducing a fix for the arrow case.
Why not go the postscript way, and introduce something like:
# set default path style,
# O for option, or D for default, or GS or S for graphics state
O setlinecap round
O setlinejoin round
O setmiterlimit 4
O setdash ....
O setcolor ...
O setlinewidth 5
H ...
...
z
L ...
If geda and lepton likes this, the next step would be to remove the
corresponding line noise from the L, H etc. directives.
> Lepton (ab-)uses the line cap field
> for that purpose, which mixes up two distinct concepts and isn't an
> acceptable solution in my opinion.
Then what would be an acceptable solution in your opinion ?
> Also, special-casing line width zero
> for filled objects kind of patches the issue here but introduces yet more
> inconsistencies.
No, it is the reverse, special-casing line width zero to be line width
5 is just wrong.
A reasonable compromise would be to use the zero to mean "as thin as
possible with the current output device", which would lend a filled path
to have an actual zero width border, an unfilled path to build with
one-pixel wide lines.
This is what PLRM2 says about the matter:
A line width of zero is acceptable: It is interpreted as the thinnest line that can
be rendered at device resolution --- in other words, one device pixel wide. Some
devices cannot reproduce one-pixel lines, and on high-resolution devices, such
lines are nearly invisible. Since the results of rendering such "zero-width" lines
are device dependent, their use is not recommended.
The only place where a zero width line makes sense is in a filled
closed path.
> > In reacent geda-gaf, a few things that was formerly allowed, now fails
> > or gets annoying error reports.
...
> As I said before, gnetlist only reports errors for situations which are
> clearly broken or can't guarantee a consistent output, and warnings for
> situations which produce an output that most probably isn't what the user
> intended. If you think a specific error or warning message doesn't fall
> in these categories, please let me know so I can look into the situation.
About the case I was thinking about, what happened with:
http://www.delorie.com/archives/browse.cgi?p=geda-user/2020/02/19/10:28:32
> As for the port/power symbol warnings you asked about a while ago, these
> were added to new-style ("portname="/"netname=") port and power symbols as
> this allows catching common user errors which used to silently result in a
> broken netlist. You can just continue to use old-style ("refdes="/"pin=")
> port and power symbols if this is an issue for you.
Ok, thanks.
Regards,
/Karl Hammar
- Raw text -