Mail Archives: geda-help/2021/03/02/11:03:16
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
- Raw text -