On Sun, 2008-09-28 at 09:50 -0400, Ales Hvezda wrote:
> [snip]
> >> I'm tired. Are you saying you prefer without the "[]", but that we
> >> should emit each segment on multiple lines by default?
> >
> >I support this, using the num_lines field as a num_segments check.
> >
> >I'm not wildly keen on re-using [], TBH. I feel that a [] should always=20
> >imply "sub-schematic", i.e. containing normal gEDA objects.
> >
>
> So we are talking about:
>
> H 3 0 0 0 -1 -1 1 -1 -1 -1 -1 -1 4
> M 410 240
> L 501 200
> L 455 295
> L 435 265
No, this is wrong..
The commas between the X and Y coordinates are part of the SVG path
string, and I don't want to deviate from that spec for no good reason.
Adding whitespace between path segments isn't a problem, if we want the
clarity.
H 3 0 0 0 -1 -1 1 -1 -1 -1 -1 -1 4
M 410,240
L 501,200
L 455,295
L 435,265
would be fine.
> Hmmmm. The only problem with this is the M's and L's. Those are
> specific to the path and have nothing to do with gschem's L's. Imagine
> what would happen if the num_lines parm was off by one. :)
Indeed, that is unplesant. Scripts have to deal with this some way or
other anyway, but for humans, some delimeters are easier to spot:
H 3 0 0 0 -1 -1 1 -1 -1 -1 -1 -1
[
M 410,240
L 501,200
L 455,295
L 435,265
]
or
H 3 0 0 0 -1 -1 1 -1 -1 -1 -1 -1
{
M 410,240
L 501,200
L 455,295
L 435,265
}
[snip, AND..]
> Here's another possibility:
>
> H 3 0 0 0 -1 -1 1 -1 -1 -1 -1 -1 X
> (
> M 410 240
> L 501 200
> L 455 295
> L 435 265
> )
>
> Not sure if you would need the above X? I'm okay with introducing (
> ) for this since it is new (I think). We could also say that ()'s can
> be used for future purposes in different contexts (suppose we introduce
> another object type that needs to take a list of points) so that people
> write their parsers with this in mind now. Thoughts/comments?
Skip the "X". I'd have to check and make sure () (or any other suggested
delimeters) aren't legal in SVG path strings for some purpose.
It is unfortunate we have so many types of delimeter. I don't think we
really need that much variety.
I think Peter B wanted to keep [] specifically because so that it isn't
"special" to any particular object type, but rather, can / could be
appended to stash embedded / cached data, as in the case of embedded
symbols.
Is there any reason not to re-use {} if we were to have a delimeter
based solution?
Best wishes,
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
