Translations of this page are also available in the following languages: Русский
A “plow” feature where the line tool shoves existing traces aside preserving the design rules when possible.
Difficulty = 4-5
Implement a fast snap rounding algorithm and resolve the case where inserted point cause self-intersection.
PCB uses an integer coordinate system for all of its objects. The polygon clipping code computes all points of intersection between two non-self-intersecting contours (among many other things it does), but these points of intersection must also have integer coordinates.
A snap-rounding algorithm replaces two segments that intersect at other than their end points with four segments where each has an end point on an integer coordinate near the original (non-integer) intersection. Because this rounding operation on the point of intersection can change the slopes of the four segments compare to that of the original two, it raises the possibility that new intersections between the replacement segments and other segments of the contours occur that did not exist with the original segments. The snap rounding algorithm needs to produce a collection of segments where all intersections occur at segment end points having integer coordinates. The existing code in pcb does this already, but it uses a theoretically slow algorithm, compared to others that are known, such as:
“Improved output-sensitive snap rounding,” John Hershberger, Proceedings of the 22nd annual symposium on Computational geometry, 2006, pp 357-366. http://doi.acm.org/10.1145/1137856.1137909
Algorithms described by de Berg, or Goodrich or Halperin, or Hobby would probably also be better than what we currently have implemented.
In addition, there are rare-but-real degenerate situations where the snap rounding results in one (or both) contours having a self-intersection that did not exist before. This self-intersection is fatal to our polygon clipping code. We do not know if the snap rounding algorithms in the literature deal with this issue or not, but if they do not, we need to develop a variant algorithm that does, whether done by judicious choice of the rounding points that are created, or a post-processing step that eliminates the self-intersection with minimal geometric distortion to the original contours.
Difficulty = 4-5
There are a number of possible enhancements related to crosshair snapping that could improve usability. For example, being able to reorder the snapping priority (what objects are snapped to before others), disabling certain objects from being snapped to, changing the radius at which a snap occurs, and others.
Ideas for how the snapping system should work are being collected here: Snapping in pcb
Basically with this tool, you would click on a starting point, then drag the crosshair to some other (typically intermediate point), possibly on another layer and an auto-routing tool would show a prospective path to that point (meeting design rules and style requirements). If you didn't like the offered path, you could hit a key to see a more expensive candidate, or a different key to (back up) to a less expensive candidate. The prospective route would dynamically change to reach the crosshair end-point as the crosshair is moved. It would disappear if no path could be found. Clicking would place the prospective path as copper and anchor a new starting point for the tool (much like the line tool does now).
Difficulty = 5
Build a footprint calculator that can take the IPC rules and produce a pcb footprint. Preferably write this in a way where the core program is independent of a GUI so that you can script it for generating entire large families of footprints or hook it up to a GUI of choice (lesstif, gtk, maybe even cgi). Would require the purchase of IPC-7351 (approximately U.S.A. $100) and verifying that one is allowed to produce such a calculator.
Difficulty = 2
Presently pcb does not present a list of recently loaded files in the file menu. It would be nice if pcb kept track of the last few files a user loaded. This is a common feature found in other programs.
Difficulty = 1
In 1997, Richard Stallman wrote: “The biggest deficiency in free operating systems is not in the software — it is the lack of good free manuals that we can include in these systems.”