X-Authentication-Warning: delorie.com: mail set sender to geda-help-bounces using -f
X-Recipient: geda-help AT delorie DOT com
X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7+dev
X-Exmh-Isig-CompType: repl
X-Exmh-Isig-Folder: inbox
From: "karl AT aspodata DOT se [via geda-help AT delorie DOT com]" <geda-help AT delorie DOT com>
To: geda-help AT delorie DOT com
Subject: file format things (was Re: [geda-help] How to get element outline off-board)
In-reply-to: <alpine.DEB.2.21.2102261538470.17675@nimbus>
References: <xnh7nchcyj DOT fsf AT envy DOT delorie DOT com> <4b1d3d85-7f93-9eac-c4eb-9f84f2a47e61 AT bitflipper DOT ca> <CAMw9acBn7xNo5jvrvS6Dof6JtYgOOLVKJwFFTu93S+CoPszjHw AT mail DOT gmail DOT com> <20210225212042 DOT 16269 DOT qmail AT stuge DOT se> <20210226140333 DOT 7D5E78248737 AT turkos DOT aspodata DOT se> <alpine DOT DEB DOT 2 DOT 21 DOT 2102261538470 DOT 17675 AT nimbus>
Comments: In-reply-to Roland Lutz <rlutz AT hedmen DOT org>
   message dated "Fri, 26 Feb 2021 16:02:03 +0100."
Mime-Version: 1.0
Content-Type: text/plain
Message-Id: <20210302140448.4E18D82475BD@turkos.aspodata.se>
Date: Tue,  2 Mar 2021 15:04:48 +0100 (CET)
X-Virus-Scanned: ClamAV using ClamSMTP
Reply-To: geda-help AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-help AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

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