On Fri, 2008-09-26 at 20:30 -0700, [EMAIL PROTECTED] wrote: > > On Sep 25, 2008, at 5:50 PM, Peter Clifton wrote: > > > > To get started, look at one of my example symbols which uses this > > feature, such as npn-1.sym. Look for a line such as: > > > > p 3 0 0 0 -1 -1 1 -1 -1 -1 -1 -1 1 > > M 410,240 L 501,200 L 455,295 L 435,265 z > > > > > To be gEDA-ish, the path line could look something like: > > > p 3 0 0 0 -1 -1 1 -1 -1 -1 -1 -1 1 > [ > M 410 240 > L 501 200 > L 455 295 > L 435 265 > ]
Mine is gEDA like too.. it copies the format of text. However, I do like the context provided you your suggestion, and it makes hand-editing easier. (I never did much like having to manually update a line-count when editing text lines). Note, that the last "1" on the "p ...." line means "one further line of path string. You'd want to drop that if you moved to the [...] syntax. The parser strips whitespace, so you could already have the path string split onto multiple lines so long as you update the line-count. Now is the right time to make such suggestions - before a release is made with this support in it. I've CC'd geda-dev to get further opinion. > To me, this format would be easier to edit manually, easier to read, > and the lines or nodes would not need to be counted... Fine by me. > > Also, could arcs be made part of paths? You can make arcs with paths, but we're not going to remove the old file-format line for arcs. To preserve saving those back out again (should we want to), we have to keep the old arc support. I've not tested them all, but in theory, all path commands from the SVG standard are supported. (At least, those which work in librsvg). http://www.w3.org/TR/SVG/paths.html#PathDataCurveCommands They will be converted to cubic bezier segments at read-time though, and saved back out as such. > > I'm almost done with an API specification for the "geometry" layer. > The geometry API includes functions for hatching arbitrary paths > (Beziers included). I noticed for the adaptive Bezier subdivision, > the view's zoom factor needs to get used. If the subdivisions get > cached, then per-view data/objects need to be created. But for now, I > guess fixed segmentation can be used. For now, keep adaptive subdivision, but don't cache the results. Seriously, the time taken to draw the segments on screen probably dwarfs the division time anyway. If it is slow, we can look at caching later. This is almost a non-issue anyway, since the cairo code _does_ support drawing these paths, and cairo is the way gschem is going (eventually). > > I'm not sure how the schematic editor will create paths, but here is > one idea. Lines an Beziers (and maybe arcs) exist as separate > objects. The user selects a group of objects, and then selects a menu > item like "Create path." Gschem then takes the selected objects and > creates the path. Some of the algorithms to perform this operation > look fairly straightforward. Possible, but does require you to land the end-points on eachother, adn that the path construction algorithm figures out the sequence of points. One gotcha would be a node with more than two objects joining it. Only two per node can form a path. Then you've got to make two paths. > > Also, in a previous post this month, Ales wanted the following > patch committed: > [PATCH] Updated selection mechanism to use interrior points for solid > shapes. > > > He didn't mention who should commit the patch, and I don't have > repository write access. Can you commit this patch? Can do, I was meaning to look at doing it, but didn't get to it yet. Now path support is in git.. we probably could do with "interior" detection for that too. (Granted, this is probably hard?) I've not firmly specified the fill rule for closed paths, but cairo rendering uses as the "winding" rule by default. See: http://cairographics.org/manual/cairo-cairo-t.html#cairo-fill-rule-t -- 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
