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: [geda-help] Re: file format things
In-reply-to: <alpine.DEB.2.21.2103021539480.9780@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> <20210302140448 DOT 4E18D82475BD AT turkos DOT aspodata DOT se> <alpine DOT DEB DOT 2 DOT 21 DOT 2103021539480 DOT 9780 AT nimbus>
Comments: In-reply-to Roland Lutz <rlutz AT hedmen DOT org>
   message dated "Tue, 02 Mar 2021 15:55:51 +0100."
Mime-Version: 1.0
Content-Type: text/plain
Message-Id: <20210302160309.76DE982475BD@turkos.aspodata.se>
Date: Tue,  2 Mar 2021 17:03:09 +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 Tue, 2 Mar 2021, karl AT aspodata DOT se [via geda-help AT delorie DOT com] wrote:
> > 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 ?
> 
> "z" is "closepath", so unless I din't get something here, these are the 
> same.

I can make a triangle with three L's. The "joins" will be each lines
cap style, so to say.

I can also make a triangle a H ended with a closepath. Here the joins
are real joins, which I have no way to control.

In the L case, the "joins" depends on the cap style.
In the H case, the joins depends on the join style.
Hence, the "equivalence" of cap and join style.

> > Why not go the postscript way, and introduce something like:
...
> I'm not terribly opposed to this.  So far, gEDA didn't even try to support 
> proper SVG paths; the current path syntax is a subset of SVG paths.  That 
> said, I don't see enough benefits in it to justify the extra complexity.
...

Ok, so how do we go forward ?

> >> 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 ?
> 
> Adding a dedicated line join field to the file format.

Ok, can we get an agreement with the lepton crew so we share the same 
file format ?

And, since I am possible the only user of the "arrow" case, I can
change my files to follow suit.

> >> 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.
> 
> It is a kind of unfortunate choice, I agree with that.  The rationale 
> behind it is that older versions of gEDA/gaf didn't support line width, 

Yea, legacy is a tough barrier...

> and you don't necessarily want to introduce that to your schematics: 
> conceptually speaking, a schematic contains a line, not a graphical object 
> with a certain width, and having a special setting "no particular width" 
> makes sense for some users.

Well, a line (L) is just a graphical element, it has no semantics other 
than what the viewer "sees". In contrast, a net (N), do have semantics.
In fact, you could (as an academic exercise) make symbols and schematics,
completely without any use of L, B and H.

So, a line is visual element and nothing else. As a visual element
line width have a meaning. Using "no particular width" is just saying
that the user isn't much caring for visual details.

I use the line width in various ways to communicate things to a viewer.

> The solution I favor would be to differentiate between "line width zero" 
> which, as you explained, means the thinnest line width supported by the 
> output device (or "no line" in the case of a filled closed path), and 
> "there's no line width set, use the default width".

The usual solution to "use default", sentinels etc. is to use an illegal
value, like -1, NULL, '\0', etc. For a line width, -1 would be suitable.
You "cannot" use zero, since mathematically, a line do have a width of
zero.

Regards,
/Karl Hammar