X-Authentication-Warning:	delorie.com: mail set sender to geda-help-bounces using -f
X-Recipient:	geda-help AT delorie DOT com
Date:	Tue, 2 Mar 2021 15:55:51 +0100 (CET)
From:	Roland Lutz <rlutz AT hedmen DOT org>
To:	"karl AT aspodata DOT se [via geda-help AT delorie DOT com]" <geda-help AT delorie DOT com>
Subject:	Re: file format things (was Re: [geda-help] How to get element
	outline off-board)
In-Reply-To:	<20210302140448.4E18D82475BD@turkos.aspodata.se>
Message-ID:	<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>
User-Agent:	Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version:	1.0
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

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.

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

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.

> If geda and lepton likes this, the next step would be to remove the
> corresponding line noise from the L, H etc. directives.

These aren't redundant.  Path objects allow for a lot of flexibility, but 
in the vast majority of cases, you'll need just a line or a box.  Imposing 
path controls on the user for these cases would be overkill.

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

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

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

Roland

- Raw text -