Index: trunk/doc-rnd/mincut.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc-rnd/mincut.png =================================================================== --- trunk/doc-rnd/mincut.png (revision 2494) +++ trunk/doc-rnd/mincut.png (nonexistent) Property changes on: trunk/doc-rnd/mincut.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc-rnd/ba.html =================================================================== --- trunk/doc-rnd/ba.html (revision 2494) +++ trunk/doc-rnd/ba.html (nonexistent) @@ -1,50 +0,0 @@ - - -

pcb-rnd - the [ba] patches

-Back annotation was a long standing missing functionality. There has been -different suggestions, including: -

back annotation is not needed at all, the user can do it manually -
pcb should generate a new netlist, the user should run diff on the netlists and manually edit the schematics -
gschem should be able to load netlists emitted by PCB; or gnetlist could reverse-process such a netlist -

-The current implementation allows pcb-rnd users to make deliberate pin -swapping and footprint replacement. The changes can be saved in a -"netlist patch" format. A modified gschem can load these and present them -as search results pointing to parts of the schematics that need to be changed. -There is a -demo video about how this happens in practice. -

-The modified gschem can be checked out from svn://repo.hu/geda-gaf-ba/trunk -

-The underlying mechanism is versatile and potentially allows more changes -to be back annotated. These are not yet accessible due to the lack of PCB -actions and GUI. - -

Design decisions

-This devlog entry functions -as a design decision document. - Another entry is a summary -on how the feature ended up in a private feature-fork of gschem. - -

save/load and compatibility

-Deliberate changes are tracked so that a new forward annotation from -the old schematics won't break them. To do this, pcb-rnd saves a -NetListPatch() section in the file. Mainline PCB can not handle this section. -Compatibility, by use case: -

1. No back annotation is made in pcb-rnd: the file stays compatible -
2. Back annotation is made in pcb-rnd, then the changes are done on the schematics and a forward annotation is also done: the netlist patch in pcb-rnd becomes empty so the pcb file is again compatible with mainline pcb; this is called resolution of netlist patches -
3. There are unresolved netlist patches saved in pcb-rnd and the user attempts to load the pcb file in mainline pcb: syntax error (but no data loss); solution: resolve the netlist patch as described in point 2. -
4. Cheat for situation 3.: manually remove the NetListPatch() section from the save file. This way the back annotation info is lost, but mainline pcb can load the file again. This action is sort of "revert back annotation". -
5. Any file saved by mainline PCB can be opened by pcb-rnd, back annotation does not affect that. - -

- - -

plans

-Back annotation for further changes, e.g. value change, naming/renaming nets, -etc. - - Index: trunk/doc-rnd/res.html =================================================================== --- trunk/doc-rnd/res.html (revision 2494) +++ trunk/doc-rnd/res.html (nonexistent) @@ -1,129 +0,0 @@ - - -

pcb-rnd - the [res] patch

- -PCB used to have an own file format for describing resources (menu structure -and hotkey bindings, vendor drill mapping). The resource format was generic -enough to describe these things, but the syntax was somewhat wierd: mixed -positional and named fields. More precisely, composite nodes could contain -named and anonymous subnodes, and the meaning of anonymous subnodes depended -on their position in the anon-subnode-list. -

-The code that dealt with the in-memory representation of the resource tree -was wierd and big chunks duplicated in the HIDs and vendor drill module. It -was also hard to parse a resource file with external tools. -

-Since version 1.0.10, pcb-rnd replaces resource files with -lihata. Lihata is a small, generic -purpose container format that can describe arbitrary trees. Just like resource -file syntax, lihata is optimized for hand-editing: no need to use excess -quoting or long boilerplate blocks. -

-Liblihata also provides a lot of helper functions that made the code -dealing with the menus and vendor drill resources much simpler and less -redundant. Since the parser is small and external, and since there are -external converter tools available, it is also easier to deal with the -files outside of the pcb executable. - -

menu files

-There are pcb-menu-gtk.lht and pcb-menu-lesstif.lht. They are in trunk/src -in the source tree and are instaslled in the SHAREDIR. Currently each GUI -HID (lesstif, gtk) loads the corresponding menu file. - -

menu resource lihata structure

-The root of a menu resource file should be a ha: with the following -children: -

li:mouse for mouse button bindings -
li:main_menu for describing the main menu -
li:popups for describing the popup menus -

-All children are optional, but recommended. Thus the file stucture, zoomed -out, is: -

-ha:{
-	li:mouse { ... }
-	li:main_menu { ... }
-	li:popups { ... }
-}
-

- -

li:mouse

-The mouse subtree may contain a li: for each mouse button action; -the children of the list are further li: nodes for key modifiers, whose -children are text nodes: actions executed in order. -

-Buttons supported are: left, right, middle, up, down - the last two -are for the scroll wheel. Modifier name should start with "press" or "release" -optionally followed by modifier key suffixes separated with dashes, e.g. -"press-alt-shift" means the given button is pressed while alt and shift -were also pressed. -

-Example structure: -

-	li:mouse {
-		li:left {
-			li:press            = { Mode(Notify) }
-			li:press-ctrl       = { Mode(Save); Mode(None); }
-		}
-	}
-

- -

li:main_menu

-The main menu is a list of menubar items that may host submenu items -recursively. Each normal item is a hash with the following children: -

li:submenu an ordered list of submenu nodes (should not have accel key or action) -
tip tooltip text -
action text or list of actions to execute when menu is selected -
a a key description for an accelerator key (hotkey) -
li:a a list of key descriptions for an accelerator keys (hotkeys); all keys will be bound to the menu and the first key is shown in the menu -

-Special menu items are text nodes instead of hashes; they are: -

starting with @, are dynamic, auto-generated items (e.g. layers; might be HID-dependent) -
a singel dash: separator -

-A key description is a text in the form of: -

the name of the node is the visible name of the menu item -
<key>keyname, e.g. "<key>k" for key K, or "<key>F10" for F10 -
modifier<key>keyname, e.g. "Alt-<key>K" for Alt+K -
modifier-modifier<key>keyname, e.g. "Shift-Alt-<key>K" for Shift+Alt+K; modifiers are Alt, Shift and Ctrl; order does not matter, all three can be used together. -
multikey sequence: multiple of the above, separated by semicolons (protected with {} for lihata, as the text contains semicolon); e.g. "{<key>f;<key>o}" means the user presses "f" then "o". Sequences can be a dozen stroke long and any segment may use modifiers -

- -An example menu item with submenus (can be a main menu or a submenu of -another menu item): -

-ha:example menu item {
-	li:submenu {
-		ha:menu item {
-			action=Save(ElementConnections)
-			tip=example menu
-		}
-		-
-		ha:another menu item {
-			a={Shift-Alt<key>r}
-			action={Action1(); Action2();}
-		}
-	}
-}
-

- -

li:popups

-Each children is a hash that describes a popup menu. A popup menu behaves -exactly like a menu item, it should have a submenu list. Popup windows will -be popped up by executing an action with the name of the popup menu. - -

save/load and compatibility

-Not affected. - -

plans

-The resource file format conversion is done. There are other parts of the code -that will probably get lihata instead of the current custom parsers, e.g. -the preferences/settings file. - - - Index: trunk/doc-rnd/pcb-fp.html =================================================================== --- trunk/doc-rnd/pcb-fp.html (revision 2494) +++ trunk/doc-rnd/pcb-fp.html (nonexistent) @@ -1,36 +0,0 @@ - - -

pcb-rnd - the [pcb-fp] patch

- -Pcb-fp is an effort to clean up the footprint situation: -

replace lib and newlib with pcblib, a library that tries to provide common footprints only -
clear the syntax: if a footprint name contains parenthesis, it's generated (parametric footprint), else it's the name of a static footprint file -
parametric footprints: replace m4 with a generic, language-independent footprint generator framework -
- implement libpcb_fp, which centralizes searching and loading footprints -
- fork gsch2pcb to gsch2pcb-rnd that uses libpcb_fp (and does not have any m4 references hardwired) -
- fork gnet_gsch2pcb.scm (the gnetlist backend) to remove m4 heuristics -
-

- -

Example

-Intaractive parametric footprint selection in pcb-rnd: -

- -

-An online footprint generator web1.0 version is also available. - -

save/load and compatibility

-Save/load files are not affected. If a schematics is written for the new -library and depends on parametric footprints: -

mainline gsch2pcb won't find those footprints -
mainline pcb won't show those footprints in the footprint selection dialog -

- -

plans

-No plans - this feature is fully implemented. - - - Index: trunk/doc-rnd/square.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc-rnd/square.png =================================================================== --- trunk/doc-rnd/square.png (revision 2494) +++ trunk/doc-rnd/square.png (nonexistent) Property changes on: trunk/doc-rnd/square.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc-rnd/gpmi.html =================================================================== --- trunk/doc-rnd/gpmi.html (revision 2494) +++ trunk/doc-rnd/gpmi.html (nonexistent) @@ -1,41 +0,0 @@ - - -

pcb-rnd - the [gpmi] patch

- -Thanks to gpmi, pcb-rnd is scriptable in about 10 scripting languages (e.g. -lua, awk, ruby, python, scheme, tcl). Scripts are integrated in pcb-rnd and -have access to most of the internals. Scripts -are able to: -

register new actions -
create new menus and submenus -
execute existing actions -
pop up simple dialog boxes (message, report, progress bar, file selection) -- check out the video -
build and pop up custom dialog boxes (so called attribute dialogs) -
search for objects (lines, arc, polys, vias, etc.) on the layout -
change and move existing objects on the layout -
create new objects on the layout -
change "page" properties (dimensions of the board) -
debug draw on the gui (slightly broken on gtk due to some gtk hid bugs) -

- -

-This feature has three options: -

disabled: not compiled at all - when gpmi is not installed (no gpmi scripting in PCB) -
buildin: compiled and linked in the executable - pcb-rnd always can load and run scripts -
plugin: compiled as a loadable plugin - pcb-rnd can load and run scripts if the plugin is installed -

- -

Example

-Check out the Rosetta stone of -pcb-rnd. - -

save/load and compatibility

-Save/load files are not affected. - -

plans

-Expose more internals, write more example scripts and documentation. - - - Index: trunk/doc-rnd/fp_wget.html =================================================================== --- trunk/doc-rnd/fp_wget.html (revision 2494) +++ trunk/doc-rnd/fp_wget.html (nonexistent) @@ -1,37 +0,0 @@ - - -

pcb-rnd - the [fp_wget] patch

- -Since version 1.0.10, pcb-rnd implements a new footprint mechanism (see -[fp_fs] and [library_t]). -The new code allows footprint backend plugins to get library from anywhere. -The [fp_wget] plugin is an implementation that: -

downloads a library list from the web on startup into a local cache -
downloads footprints from the web on-demand into a local cache -

-This is all transparent, the user experience is that the remote library is -like a read-only local library reachable from the library window. -

-A web site used as a library should be able to: -

generate a plain text list of all footprints available -
return the raw footprint file by name -

-The plugin uses external program wget to communicate on the web. - - -

How to configure for gedasymbols.org

-Add wget@gedasymbols in the library search path (e.g. in preferences as library-newlib). - -

save/load and compatibility

-Not affected. - -

plans

-Better feedback on progress, explicit user requested refresh, refresh in -the background. - - - Index: trunk/doc-rnd/unglib.html =================================================================== --- trunk/doc-rnd/unglib.html (revision 2494) +++ trunk/doc-rnd/unglib.html (nonexistent) @@ -1,17 +0,0 @@ - - -

pcb-rnd - the [unglib] patch

- -Removes glib dependency from core, in favor of -minilibs to help -keeping the code small, modular -and easier to fix. - -

save/load and compatibility

-Not affected. - -

plans

-Remove glib dependency from the puller plugin. - - - Index: trunk/doc-rnd/jumper_1206.fp =================================================================== --- trunk/doc-rnd/jumper_1206.fp (revision 2494) +++ trunk/doc-rnd/jumper_1206.fp (nonexistent) @@ -1,7 +0,0 @@ -Element["nonetlist" "1206 jumper, 0 ohm" "" "1206" 0 0 -3150 -3150 0 100 ""] -( - Pad[-5905 -1181 -5905 1181 5118 2000 5718 "1" "1" "square,intconn(1)"] - Pad[5905 -1181 5905 1181 5118 2000 5718 "2" "2" "square,intconn(1)"] - ElementLine[-2362 -3740 2362 -3740 800] - ElementLine[-2362 3740 2362 3740 800] -) Index: trunk/doc-rnd/cycdrag.html =================================================================== --- trunk/doc-rnd/cycdrag.html (revision 2494) +++ trunk/doc-rnd/cycdrag.html (nonexistent) @@ -1,28 +0,0 @@ - - -

pcb-rnd - the [cycdrag] patches

- -A long standing misfeature of pcb (and pcb-rnd) has been that when dragging the -end of connected traces, pcb chosen one of the traces "randomly". It often -didn't pick the one the user wanted to move. The workaround was to move the -one that pcb picked and then return and move the target trace then -move the other trace back. This gets even more annoying if there are more than -two objects connected in the given point: 3 traces and a via for example. -

-The cycdrag patch addresses this issue by defining an action that can cycle -through objects that could be dragged in the given point while the left mouse -button is pressed. This lets the user explicitly select the one object to -work on. -

-This demo video -demonstrates how it works with three lines and a via. - -

save/load and compatibility

-Not affected. - -

plans

-It does not work with the lesstif HID. It does not work with the rubber band -mode. - - - Index: trunk/doc-rnd/negselect.html =================================================================== --- trunk/doc-rnd/negselect.html (revision 2494) +++ trunk/doc-rnd/negselect.html (nonexistent) @@ -1,23 +0,0 @@ - - -

pcb-rnd - the [cycdrag] patches, negative box select

- -When a selection is made using drag&drop (box selection), depending -on the direction the rule for object selection differ: -

drag from top-right towards bottom-left (positive sized box): - select objects that are fully contained in the box (original behaviour) -
drag from bottom-left towards top-right (negative sized box): - select objects that are even partially within the box or merely touch - the edge of the box -

- -

save/load and compatibility

-Not affected. - -

plans

-Work more on some rough corners of the negative direction: e.g. pads are -handled as 0 width lines so the selection has to hit the center. - - - Index: trunk/doc-rnd/debian.html =================================================================== --- trunk/doc-rnd/debian.html (revision 2494) +++ trunk/doc-rnd/debian.html (nonexistent) @@ -1,18 +0,0 @@ - - -

pcb-rnd - the [debian] patch

- -The name of the package has been changed to pcb-rnd; a conflict with the -mainline pcb is set. -

-The lesstif variant and pcb documentation are not compiled or packaged -- I don't need them. The possibility is still there to compile them, tho. -

-The gtk variant (pcb-rnd-gtk) has both dbus and gl disabled. -

-Versioning scheme changed to match svn revisions and tags of pcb-rnd. - -

plans

-No plans - this feature is fully implemented. - - Index: trunk/doc-rnd/scconfig.html =================================================================== --- trunk/doc-rnd/scconfig.html (revision 2494) +++ trunk/doc-rnd/scconfig.html (nonexistent) @@ -1,15 +0,0 @@ - - -

pcb-rnd - the [scconfig] patch

- -Pcb-rnd uses scconfig -for ./configure instead of autotools. Scconfig is smaller and easier -to maintain. - -

save/load and compatibility

-Not affected. - -

plans

-No plans - this feature is fully implemented by now. - - Index: trunk/doc-rnd/library_t.html =================================================================== --- trunk/doc-rnd/library_t.html (revision 2494) +++ trunk/doc-rnd/library_t.html (nonexistent) @@ -1,28 +0,0 @@ - - -

pcb-rnd - the [library_t] patch

- -The original code has a special setup for representing trees, C structures -called LibraryMenu and LibraryEntry. This system can represent only a subset -of trees: there is a root, a level consist of directories only and a next level, -each directory consist of data nodes only. This has been enough for newlib, -which strictly follows this model in the file system hierarchy. The lesstif -HID also hardwired this model in the GUI. -

-In pcb-rnd this has been replaced with a new struct type called library_t -that can represent an arbitrary tree: directories and files within directories -down to many levels. -

-Both the gtk and the lesstif had has been modified accordingly and can -properly display the tree. This in turn enables alternative footprint backend -implementations such as fp_wget to import -more complex libraries, e.g. the one on gedasymbols.org. - -

save/load and compatibility

-Not affected. - -

plans

pcb-rnd - the [mincut] patch

- -The original code was highlighting pins/pads only when a short came around -after rats nest optimization. This was not very helpful on a complex board. -There had been a long discussion on the mailing list about the best solutions. -There were a few very good ideas, including: -

manual tagging of objects (lines, polys, arcs, vias) with net and warn - where two differently tagged net connects -
automatic tagging based on "where it was connected first", then the same - warning mechanism as above -
trace history (using the undo buffer?) and go back until when it was - not broken, check what exactly broke it -
history combined with tagging -
calculate minimal cut -

-I choose minimal cut for my patch because it doesn't require tracing the -full history or any manual administration of nets vs. objects (which I -would find inevitable even with manual tagging - directly or indirectly -the user needs to be able to change net tags). -

-The minimal cut is the least amount of object whose removal would resolve -the short. It is best demonstrated on an example: -

- -

-Removing all the marked lines/polys/vias would surely resolve the short -(sometimes leaving rat lines behind). Minimal cut is better than randomly -removing objects, tho: it guarantees that the minimal amount of objects -are to be removed. On a complex board, this place is likely to be close -to the place where the problem really is - much closer than the pins/pads. -

-Since mincut can be expensive on large boards, the feature can be enabled -per board (a new PCB flag) and can be disbaled globally (--enable-mincut 0 -when starting PCB). - -

save/load and compatibility

-New PCB flag enablemincut. Mainline pcb ignores this flag but does not -preserve it. - -

plans

-Finished, no plans. - - Index: trunk/doc-rnd/flagcomp.html =================================================================== --- trunk/doc-rnd/flagcomp.html (revision 2494) +++ trunk/doc-rnd/flagcomp.html (nonexistent) @@ -1,23 +0,0 @@ - - -

pcb-rnd - the [flagcomp] patch

- -Many of the patches in this fork, and in possible future branches/forks -may introduce new pin, pad or element flags. PCB loads and saves flags -by converting the text representation to an in-memory binary format. Any -flag not understood is lost. -

-This patch adds a linked list of string flags, filled in with the unknown -flags while loading a PCB. On save, these flags are appended to the normal -flag list. This preserves all unknown flags (but not order of flags) in -a load/save cycle. - -

save/load and compatibility

-This patch ensures compatibility in save/load cycles with flags introduced -by later versions of mainline PCB or different branches/forks of PCB by -not removing flags they introduced. - -

plans

-No plans - this feature is fully implemented. - - Index: trunk/doc-rnd/square.html =================================================================== --- trunk/doc-rnd/square.html (revision 2494) +++ trunk/doc-rnd/square.html (nonexistent) @@ -1,71 +0,0 @@ - - -

pcb-rnd - the [square] patch

-Most of my PCBs end up in toner transfer. There are a lot -of tricks around prototyping at home. One of the problems I often -face is small rings peeling off during rework (and rework tend to -happen on the first prototypes). The solution for this is increasing -ring size - which is not suitable if traces are passing between pins. -Another solution is to increase the area of the pin: -

square pin: while it makes the pin slightly larger still letting traces pass between pins, it's too symmetrical and can not use up extra room -
DJ's teardrop plugin: this increases the area only toward the trace, whereas very often there's more room on the opposite side -
manually add an extra poly around the pin; with multiple pins it's hard to get the polys separate -
manually add a short extra track on the pin, width matching the size of the pin; this is very close, but increases workload when components are moved, layers are changed -

-The patch takes an octagon pin and stretches points in various directions. -There are 4 bits (for left, right, up and down) to indicate in which directions -the stretch applies. Pressing 'q' on a pin cycles thru round pin, square pin, -16 stretched octagons and the original octagon. -

-The code is also patched to handle clearances, shorts and connections (find.c). -

-Thermals are not fully working for funny shaped pins, but it has low priority: -they still work fine for rounded and square pins and if there is a poly around -the pin, I wouldn't use shaped pins anyway. - -

save/load and compatibility

-This patch introduces a new pin flag called shape(n), where n is an integer -selecting the shape of the pin when the square flag is also set: -

-Pin[40000 60000 6000 3000 6600 2800 "8" "8" "square,shape(3)"]
-

-Mainline PCB will load the design ignoring the custom shape and will use a -square pin. As long a traces end in the center point of the pin, this -should not break connections. -

-Mainline PCB doesn't save shape() - once the design is loaded and saved with -mainline PCB pin shape info is lost. - -

plans

-In the original code there are separate code paths for round, octagonal and -square pins. The separation repeats for at least: -

drawing the pin shape -
calculating the clearance -
checking whether things overlap or connect (pin vs pin, pin vs line, etc.) -
autorouter -

-In most cases a set of hardwired constants are written in the C code. A notable -exception was the octagon pin draw function, that had x and y offsets in a const -table for 8 points and a loop to create the poly (or line segments in thin draw). -

-The [square] feature is a good base for cleaning up the code a bit and for -moving toward a generic pin shape patch: -

hardwired octagon calculations should be replaced to use the same x;y const offset table -
the table should be replaced by a struct that describes length (number of points) - alternatively use POLYAREA -
square pin should be renamed to polygon pin -
octagon flag shall be removed - it should be a configuration of the x;y const table -
square flag shall be removed - it should be a configuration -
the only flag remaining should be shape(); if a pin is not shaped, it's round -
the pin shape struct should have a field for compatibility - to mark the entry corresponding to the original square and octagon pins so PCB-rnd format can be converted to and from the mainline PCB format. -
there should be a set of pin shapes in a default configuration table, including square and octagonal; these should be static -
the PCB file format should be extended with an option to expand the pin shape table with custom shapes -
UI: shapes could be imported (converted) from polys around vias -
UI: since there may be a lot of pin shapes, a GUI selector alternative shall be offered while also keeping the cycle-thru 'q' key -

- - Index: trunk/doc-rnd/intconn.html =================================================================== --- trunk/doc-rnd/intconn.html (revision 2494) +++ trunk/doc-rnd/intconn.html (nonexistent) @@ -1,64 +0,0 @@ - - -

pcb-rnd - the [intconn] patch

- -There are parts with internal connections (e.g. pin 2 and 4 of a SO8 -package are internally connected). Mainline PCB can not handle this, -leaving the following options: -

connect both pins to the net from the schematics - this works if all the internally connected pins are required to connect to copper (common with GND or power pins) but is very inconvenient for signal pins where only one of them needs to be connected -
back-annotate which pin is connected - there's no easy back annotation -
one pin connected, the other is closer to the next target; PCB doesn't understand that they are already connected internally; normally one shouldn't use the internal connection of a component instead of copper; except for the common practice to use 0 ohm SMD resistors for jumping wires -

-The patch introduces a new pin flag intconn(g) which marks the pin -to have internal connections in group g. If there -are multiple pins using the same g value within a single element, they -are internally connected. In other words, g is a group (or net name) -within the element and pins can join to one of the numbered groups (or internal -nets). The value of g shall be between 1 and 255, 0 means no internal -connection (equivalent to the case when intconn(0) is omitted). -

-When pin numbers are displayed (key 'd'), internal connection groups are -written in square brackets, e.g. "2 [9]" means "pin 2, internally connected -to group 9". -

-Combined with the [nonetlist] patch, this -solves the "0-ohm 1206 jumper" problem: the element should be marked -as nonetlist, with both pins set intconn(1) - this will result in a 2 -pad element, pads internally connected, that can be part of any one network -without causing short. -

Example

-Crossing traces resolved using a 0 Ohm 1206 resistor called J1. The footprint -has an intconn between the two pads which resolves the final rat line. -

- -

- - - -

save/load and compatibility

-This patch introduces a new pin flag. In the following example -pin 2 and 4 are connected internally as group 9, while pin 3 -does not have any internal connections: -

-Pin[40000 60000 6000 3000 6600 2800 "2" "2" "square,intconn(9)"]
-Pin[40000 50000 6000 3000 6600 2800 "3" "3" "square"]
-Pin[40000 40000 6000 3000 6600 2800 "4" "4" "square,intconn(9)"]
-

-Mainline PCB will load the design ignoring internal connections - -this may introduce new rats. -

-Mainline PCB doesn't save intconn() and elements are embedded in the file - -once the design is loaded and saved with mainline PCB, internal connection -info is lost. - -

plans

-No plans - this feature is fully implemented. There is no plan for implementing -a GUI, internal connections should be hand-edited into the element. - - Index: trunk/doc-rnd/onpoint.html =================================================================== --- trunk/doc-rnd/onpoint.html (revision 2494) +++ trunk/doc-rnd/onpoint.html (nonexistent) @@ -1,50 +0,0 @@ - - -

pcb-rnd - the [onpoint] patches

- -Robert Drehmel writes: -

-When (e.g.) routing 5mm power traces on a small grid, it's not always easy to hit the
-point where the trace ended (which is the center of the semicircle at the end of the
-line) to start the next line.  If you have selected the line tool, finding the end of
-the line can become guesswork as the cursor doesn't change shape like it does with the
-select tool.
-I want my traces to consist of lines and arcs that are perfectly connected and I want
-to work as fast as possible.
-
-Attached is a small patch that
-
-  - makes it possible to deactivate snapping to "some sensible point along a line".
-    (that's what a comment in the code says). This snapping algorithm gets in the way
-    sometimes so you have to slowly go over a line to find out where it really ends,
-    bouncing back and forth between the points of the small grid, the end of the line
-    and these "sensible points", which is wasting time. The command is
-    "Display(ToggleSnapOffGridLine)". It is still activated by default to avoid
-    violating POLA.
-
-  - more importantly, introduces a new command called "Display(ToggleHighlightOnPoint)"
-    that highlights all lines and arcs which have (end)points exactly on the position
-    where the cross hair is currently snapped to. It therefore helps finding the end
-    points of lines and arcs, but sometimes also shows redundant traces, traces that
-    aren't perfectly connected to each other, traces that don't end directly on the
-    center of a via but should, etc. It works with thin draw too and I tested it with
-    gtk and lesstif.
-
-I use the second option mostly in conjunction with deactivating the first. Both commands
-have been added to the menu by means of (g)pcb-menu.res.in and are available as command
-line options as well.
-Caveats:
-  - The HID API expects all HIDs to make a copy of the color string when setting a color.
-  - The function that lightens up a color could be improved.
-  - I used it for a while, but after porting it from my local fork, it probably needs
-    more testing.
-

- -

save/load and compatibility

-Not affected. - -

plans

-The feature is complete. - - - Index: trunk/doc-rnd/io.html =================================================================== --- trunk/doc-rnd/io.html (revision 2494) +++ trunk/doc-rnd/io.html (nonexistent) @@ -1,23 +0,0 @@ - - -

pcb-rnd - the [io_*] patches

- -Mainline PCB core was coupled with the file format; the [io] patch set is -an effort to decouple any file design I/O from core. The original file format -(plain text .pcb and .fp) lives on as plugin called io_pcb. - -

-TODO - -

save/load and compatibility

-Not affected when io_pcb is used and .pcb or .fp files are loaded or saved. -

-Using other io_* implementations will obviously result in files that are -incompatible with mainline pcb (unless mainline pcb learns how to load those -formats). - -

plans

-The project is still in an early phase. - - - Index: trunk/doc-rnd/intconn3.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc-rnd/intconn3.png =================================================================== --- trunk/doc-rnd/intconn3.png (revision 2494) +++ trunk/doc-rnd/intconn3.png (nonexistent) Property changes on: trunk/doc-rnd/intconn3.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc-rnd/intconn2.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc-rnd/intconn2.png =================================================================== --- trunk/doc-rnd/intconn2.png (revision 2494) +++ trunk/doc-rnd/intconn2.png (nonexistent) Property changes on: trunk/doc-rnd/intconn2.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc-rnd/intconn1.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc-rnd/intconn1.png =================================================================== --- trunk/doc-rnd/intconn1.png (revision 2494) +++ trunk/doc-rnd/intconn1.png (nonexistent) Property changes on: trunk/doc-rnd/intconn1.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc-rnd/nonetlist.html =================================================================== --- trunk/doc-rnd/nonetlist.html (revision 2494) +++ trunk/doc-rnd/nonetlist.html (nonexistent) @@ -1,53 +0,0 @@ - - -

pcb-rnd - the [nonetlist] patch

- -The [nonetlist] patch adds an element flag that makes PCB ignore the marked -element when dealing with netlists. This means connecting a net to a pin of -a nonetlist element will not cause a short. The refdes of a nonetlist -part is drawn with color element-color-nonetlist (ElementColor_nonetlist -in the source; default value #777777, grey). -

-Uses of the nonetlist feature: -

smd jumper: Combined with the [intconn] patch, this - solves the "0-ohm 1206 jumper" problem: the element should be marked - as nonetlist, with both pins set intconn(1) - this will result in a 2 - pad element, pads internally connected, that can be part of any one network - without causing short. -
mechanical parts that should not show up on the schematics: -
- mounting hole elements: single pin holes with silk marking the head of the screw -
- chassis (often with mounting holes or keep-out areas) -
- logos in footprints (no poly support in footprint - yet?) -
- mechanical parts which do not have solderable pins (plastic spacers, extra connector shields) -
- "spare parts", e.g. unused/disconnected DIP sockets or pin grids or connectors in a corner of the PCB for prototyping (dev-board style) -
-

-Preservation: gsch2pcb-rnd leaves nonetlist elements in the PCB. -

save/load and compatibility

-This patch introduces a new element flag. The following example demonstrates -a 1206 jumper footprint: -

-Element["nonetlist" "1206 jumper, 0 ohm" "" "1206" 0 0 -3150 -3150 0 100 ""]
-(
-	Pad[-5905 -1181 -5905 1181 5118 2000 5718 "1" "1" "square,intconn(1)"]
-	Pad[5905 -1181 5905 1181 5118 2000 5718 "2" "2" "square,intconn(1)"]
-	ElementLine[-2362 -3740 2362 -3740 800]
-	ElementLine[-2362 3740 2362 3740 800]
-)
-

-Mainline PCB will load the design ignoring internal connections and nonetlist -flag - this will cause shorts on all connected pins/pads and will break -the connection. -

-Mainline PCB doesn't save nonetlist and elements are embedded in the file - -once the design is loaded and saved with mainline PCB, the flag is lost. -After reloading the file in pcb-rnd, the element causes the same shorts -as in mainline PCB. - -

plans

-No plans, the feature is complete. - - Index: trunk/doc-rnd/pcblib.html =================================================================== --- trunk/doc-rnd/pcblib.html (revision 2494) +++ trunk/doc-rnd/pcblib.html (nonexistent) @@ -1,56 +0,0 @@ - - -

pcb-rnd - the [pcblib] and [pcblib-param] and [fp_fs] patches

- -

-The footprint library shipped with mainline pcb is cluttered with -special puprose parts. I believe PCB encourages the user from -an early stage to build his own library. Thus the purpose of -the library shipped with PCB should be -to provide a minimal collection of real essential footprints ... -

... for the very beginning of the learning curve; -
... and to be the core of the user's own library later. -

-[pcblib] is a replacement of newlib/ and lib/ and the m4 macros with -such an essential core library of static footprints ("file elements") -and easier-to-use parametric footprints. -

-There is an online map of -the library and -an online interface to the parametric footprint generators. - -

Design decisions

-Parts are sorted only in a few directories: smd, tru-hole, connector and -parametric. I believe there are so many orthogonal properties of footpritns -that there's no obvious hierarchy. Also, pcblib contains much fewer footpritns -than newlib so it should be still easy to navigate. -

-Parametric footprints are in a separate directory for now, even tho they -would fit under smd, tru-hole or connector. The reason is purely historical -and the layout may change in the future. - -

Example

-To the right: Footprint selection dialog on pcblib, with the smd directory -open. Note how few smd parts are there. Still, smd/ is the most crowded -subdirectory! - -

[fp_fs]

-As of vesion 1.0.10, the footprint list/search/load of footprints is a plugin. -The original code that handles local file system footprint libraries (e.g. -pcblib or newlib) is now a plugin. Altnerative plugins can be provided that work -from databases or from the web. In extreme -situations the file system based footprint plugin can even be disabled. - -

save/load and compatibility

-Not affected: elements are embedded in the PCB. - -

plans

-None, the feature is complete. -

- - Index: trunk/doc-rnd/pcb-fp.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc-rnd/pcb-fp.png =================================================================== --- trunk/doc-rnd/pcb-fp.png (revision 2494) +++ trunk/doc-rnd/pcb-fp.png (nonexistent) Property changes on: trunk/doc-rnd/pcb-fp.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc-rnd/polygrid.html =================================================================== --- trunk/doc-rnd/polygrid.html (revision 2494) +++ trunk/doc-rnd/polygrid.html (nonexistent) @@ -1,17 +0,0 @@ - - -

pcb-rnd - the [polygrid] patch

- -Polygrid adds an option to the ps exporter to fill polygons with a grid -of horizontal and vertical lines instead of full fill. When toner transfer -is used or test prints are produced, the grid may save some toner. - -

save/load and compatibility

-Not affected. - -

plans

-Fix bugs. -

-No (feature) plans - this feature is fully implemented. - - Index: trunk/doc-rnd/pcblib.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc-rnd/pcblib.png =================================================================== --- trunk/doc-rnd/pcblib.png (revision 2494) +++ trunk/doc-rnd/pcblib.png (nonexistent) Property changes on: trunk/doc-rnd/pcblib.png ___________________________________________________________________ Deleted: svn:mime-type ## -1 +0,0 ## -application/octet-stream \ No newline at end of property Index: trunk/doc-rnd/tostyle.html =================================================================== --- trunk/doc-rnd/tostyle.html (revision 2494) +++ trunk/doc-rnd/tostyle.html (nonexistent) @@ -1,50 +0,0 @@ - - -

pcb-rnd - the [tostyle] patch

- -Footprints bring their own hole sizes, copper ring sizes and clearances. -These parameters often depend on the manufacturing process, and such a value -coming from a footprint may differ much from the values used on the board already. -

-PCB has actions (and menus and hotkeys) to change sizes manually. In my practice, -I try to stick to the sizes defined in my routing styles and try to avoid -manually changing clearances or ring sizes. Still, the random values coming -from various footprints should be changed. -

-After many years of struggling with this, I realized the feature I need is -a way to change object sizes to not a relative or absolute number but -to the current routing style. The [tostyle] patch does exactly this. -It implements the following new features: -

change clearance size now works on elements: it changes the clearance of all pins/pads; this is the same as change drill has been working for a long time -
size change actions normally take a value and a unit; if the value is not a number but text style, the value is copied from the currently active routing style -
a new ChangeSizes() action that attempts to execute the other three change size actions with the same arguments and fails only if all of them failed; the three sizes are: main size, drill size, clearance size -
a menu item and hotkey binding to key 'Shift+Y' (for routing stYle) that calls ChangeSizes() of the selected or current object(s) to resize them to the current routing style -

-The new route style set works on: -

lines and arcs: sets their line width and clearance -
vias and individual pins: sets their ring dia, drill dia and clearance -
individual pads: sets their clearance -
elements: set all their pins and pads -

- -

Example

-GUI: select a routing style; hover above a line, a via, a pin/pad of an element -or the silk of an element; press Shift+Y; undo if necessary. -

-CLI: select objects, execute action ChangeSizes(selected, style) -

-CLI: to adjust drill sizes only: select objects, execute action ChangeDrillSize(selected, style) - - -

save/load and compatibility

-Not affected, since the patch introduces actions and UI changes, no change -related to the data model. - -

plans

-No plans, the feature is complete. - - - Index: trunk/doc-rnd/dynstyle.html =================================================================== --- trunk/doc-rnd/dynstyle.html (revision 2494) +++ trunk/doc-rnd/dynstyle.html (nonexistent) @@ -1,20 +0,0 @@ - - -

pcb-rnd - the [dynstyle] patch

- -Pcb-rnd doesn't have a hardwired limit on number of routing styles -anymore. Routing styles can be created on the fly and are saved to and loaded -from .pcb files. -

-There's no theoretical maximum explicitly set either. An implicit maximum -exists and is sizeof(int) - should be at least 2^31 on most systems. - -

save/load and compatibility

-The first 4 styles are loaded and preserved by mainline. Styles above -4 would probably be deleted in a mainline load-save cycle. The number 4 -is a constant value that can be changed if mainline is recompiled. - -

plans

-GUI HID representation of styles (especially in menus) need more testing. - - Index: trunk/doc-rnd/settings.html =================================================================== --- trunk/doc-rnd/settings.html (revision 2494) +++ trunk/doc-rnd/settings.html (nonexistent) @@ -1,31 +0,0 @@ - - -

pcb-rnd - settings

- -There are a few minor changes in default settings compared to mainline -pcb. - - - - - -

name -	description -	where to change - -
layers -	the default layer stack is optimized for two sided boards with 3 layers on both sides -	edit or replace /usr/share/pcb-rnd/default.pcb - -
styles & DRC -	default styles and DRC settings are optimized for toner transfer -	edit or replace /usr/share/pcb-rnd/default.pcb - -
grid -	on startup "enable visible grid" is on and grid is set to 25 mil -	grep "SET.* grid" main.c - -

- - - Index: trunk/doc-rnd/features/ba.html =================================================================== --- trunk/doc-rnd/features/ba.html (nonexistent) +++ trunk/doc-rnd/features/ba.html (revision 2495) @@ -0,0 +1,50 @@ + + +

pcb-rnd - the [ba] patches

+Back annotation was a long standing missing functionality. There has been +different suggestions, including: +

back annotation is not needed at all, the user can do it manually +
pcb should generate a new netlist, the user should run diff on the netlists and manually edit the schematics +
gschem should be able to load netlists emitted by PCB; or gnetlist could reverse-process such a netlist +

+The current implementation allows pcb-rnd users to make deliberate pin +swapping and footprint replacement. The changes can be saved in a +"netlist patch" format. A modified gschem can load these and present them +as search results pointing to parts of the schematics that need to be changed. +There is a +demo video about how this happens in practice. +

+The modified gschem can be checked out from svn://repo.hu/geda-gaf-ba/trunk +

+The underlying mechanism is versatile and potentially allows more changes +to be back annotated. These are not yet accessible due to the lack of PCB +actions and GUI. + +

Design decisions

+This devlog entry functions +as a design decision document. + Another entry is a summary +on how the feature ended up in a private feature-fork of gschem. + +

save/load and compatibility

+Deliberate changes are tracked so that a new forward annotation from +the old schematics won't break them. To do this, pcb-rnd saves a +NetListPatch() section in the file. Mainline PCB can not handle this section. +Compatibility, by use case: +

1. No back annotation is made in pcb-rnd: the file stays compatible +
2. Back annotation is made in pcb-rnd, then the changes are done on the schematics and a forward annotation is also done: the netlist patch in pcb-rnd becomes empty so the pcb file is again compatible with mainline pcb; this is called resolution of netlist patches +
3. There are unresolved netlist patches saved in pcb-rnd and the user attempts to load the pcb file in mainline pcb: syntax error (but no data loss); solution: resolve the netlist patch as described in point 2. +
4. Cheat for situation 3.: manually remove the NetListPatch() section from the save file. This way the back annotation info is lost, but mainline pcb can load the file again. This action is sort of "revert back annotation". +
5. Any file saved by mainline PCB can be opened by pcb-rnd, back annotation does not affect that. + +

+ + +

plans

+Back annotation for further changes, e.g. value change, naming/renaming nets, +etc. + + Index: trunk/doc-rnd/features/cycdrag.html =================================================================== --- trunk/doc-rnd/features/cycdrag.html (nonexistent) +++ trunk/doc-rnd/features/cycdrag.html (revision 2495) @@ -0,0 +1,28 @@ + + +

pcb-rnd - the [cycdrag] patches

+ +A long standing misfeature of pcb (and pcb-rnd) has been that when dragging the +end of connected traces, pcb chosen one of the traces "randomly". It often +didn't pick the one the user wanted to move. The workaround was to move the +one that pcb picked and then return and move the target trace then +move the other trace back. This gets even more annoying if there are more than +two objects connected in the given point: 3 traces and a via for example. +

+The cycdrag patch addresses this issue by defining an action that can cycle +through objects that could be dragged in the given point while the left mouse +button is pressed. This lets the user explicitly select the one object to +work on. +

+This demo video +demonstrates how it works with three lines and a via. + +

save/load and compatibility

+Not affected. + +

plans

+It does not work with the lesstif HID. It does not work with the rubber band +mode. + + + Index: trunk/doc-rnd/features/debian.html =================================================================== --- trunk/doc-rnd/features/debian.html (nonexistent) +++ trunk/doc-rnd/features/debian.html (revision 2495) @@ -0,0 +1,18 @@ + + +

pcb-rnd - the [debian] patch

+ +The name of the package has been changed to pcb-rnd; a conflict with the +mainline pcb is set. +

+The lesstif variant and pcb documentation are not compiled or packaged +- I don't need them. The possibility is still there to compile them, tho. +

+The gtk variant (pcb-rnd-gtk) has both dbus and gl disabled. +

+Versioning scheme changed to match svn revisions and tags of pcb-rnd. + +

plans

+No plans - this feature is fully implemented. + + Index: trunk/doc-rnd/features/dynstyle.html =================================================================== --- trunk/doc-rnd/features/dynstyle.html (nonexistent) +++ trunk/doc-rnd/features/dynstyle.html (revision 2495) @@ -0,0 +1,20 @@ + + +

pcb-rnd - the [dynstyle] patch

+ +Pcb-rnd doesn't have a hardwired limit on number of routing styles +anymore. Routing styles can be created on the fly and are saved to and loaded +from .pcb files. +

+There's no theoretical maximum explicitly set either. An implicit maximum +exists and is sizeof(int) - should be at least 2^31 on most systems. + +

save/load and compatibility

+The first 4 styles are loaded and preserved by mainline. Styles above +4 would probably be deleted in a mainline load-save cycle. The number 4 +is a constant value that can be changed if mainline is recompiled. + +

plans

+GUI HID representation of styles (especially in menus) need more testing. + + Index: trunk/doc-rnd/features/flagcomp.html =================================================================== --- trunk/doc-rnd/features/flagcomp.html (nonexistent) +++ trunk/doc-rnd/features/flagcomp.html (revision 2495) @@ -0,0 +1,23 @@ + + +

pcb-rnd - the [flagcomp] patch

+ +Many of the patches in this fork, and in possible future branches/forks +may introduce new pin, pad or element flags. PCB loads and saves flags +by converting the text representation to an in-memory binary format. Any +flag not understood is lost. +

+This patch adds a linked list of string flags, filled in with the unknown +flags while loading a PCB. On save, these flags are appended to the normal +flag list. This preserves all unknown flags (but not order of flags) in +a load/save cycle. + +

save/load and compatibility

+This patch ensures compatibility in save/load cycles with flags introduced +by later versions of mainline PCB or different branches/forks of PCB by +not removing flags they introduced. + +

plans

+No plans - this feature is fully implemented. + + Index: trunk/doc-rnd/features/fp_wget.html =================================================================== --- trunk/doc-rnd/features/fp_wget.html (nonexistent) +++ trunk/doc-rnd/features/fp_wget.html (revision 2495) @@ -0,0 +1,37 @@ + + +

pcb-rnd - the [fp_wget] patch

+ +Since version 1.0.10, pcb-rnd implements a new footprint mechanism (see +[fp_fs] and [library_t]). +The new code allows footprint backend plugins to get library from anywhere. +The [fp_wget] plugin is an implementation that: +

downloads a library list from the web on startup into a local cache +
downloads footprints from the web on-demand into a local cache +

+This is all transparent, the user experience is that the remote library is +like a read-only local library reachable from the library window. +

+A web site used as a library should be able to: +

generate a plain text list of all footprints available +
return the raw footprint file by name +

+The plugin uses external program wget to communicate on the web. + + +

How to configure for gedasymbols.org

+Add wget@gedasymbols in the library search path (e.g. in preferences as library-newlib). + +

save/load and compatibility

+Not affected. + +

plans

+Better feedback on progress, explicit user requested refresh, refresh in +the background. + + + Index: trunk/doc-rnd/features/gpmi.html =================================================================== --- trunk/doc-rnd/features/gpmi.html (nonexistent) +++ trunk/doc-rnd/features/gpmi.html (revision 2495) @@ -0,0 +1,41 @@ + + +

pcb-rnd - the [gpmi] patch

+ +Thanks to gpmi, pcb-rnd is scriptable in about 10 scripting languages (e.g. +lua, awk, ruby, python, scheme, tcl). Scripts are integrated in pcb-rnd and +have access to most of the internals. Scripts +are able to: +

register new actions +
create new menus and submenus +
execute existing actions +
pop up simple dialog boxes (message, report, progress bar, file selection) -- check out the video +
build and pop up custom dialog boxes (so called attribute dialogs) +
search for objects (lines, arc, polys, vias, etc.) on the layout +
change and move existing objects on the layout +
create new objects on the layout +
change "page" properties (dimensions of the board) +
debug draw on the gui (slightly broken on gtk due to some gtk hid bugs) +

+ +

+This feature has three options: +

disabled: not compiled at all - when gpmi is not installed (no gpmi scripting in PCB) +
buildin: compiled and linked in the executable - pcb-rnd always can load and run scripts +
plugin: compiled as a loadable plugin - pcb-rnd can load and run scripts if the plugin is installed +

+ +

Example

+Check out the Rosetta stone of +pcb-rnd. + +

save/load and compatibility

+Save/load files are not affected. + +

plans

+Expose more internals, write more example scripts and documentation. + + + Index: trunk/doc-rnd/features/intconn.html =================================================================== --- trunk/doc-rnd/features/intconn.html (nonexistent) +++ trunk/doc-rnd/features/intconn.html (revision 2495) @@ -0,0 +1,64 @@ + + +

pcb-rnd - the [intconn] patch

+ +There are parts with internal connections (e.g. pin 2 and 4 of a SO8 +package are internally connected). Mainline PCB can not handle this, +leaving the following options: +

connect both pins to the net from the schematics - this works if all the internally connected pins are required to connect to copper (common with GND or power pins) but is very inconvenient for signal pins where only one of them needs to be connected +
back-annotate which pin is connected - there's no easy back annotation +
one pin connected, the other is closer to the next target; PCB doesn't understand that they are already connected internally; normally one shouldn't use the internal connection of a component instead of copper; except for the common practice to use 0 ohm SMD resistors for jumping wires +

+The patch introduces a new pin flag intconn(g) which marks the pin +to have internal connections in group g. If there +are multiple pins using the same g value within a single element, they +are internally connected. In other words, g is a group (or net name) +within the element and pins can join to one of the numbered groups (or internal +nets). The value of g shall be between 1 and 255, 0 means no internal +connection (equivalent to the case when intconn(0) is omitted). +

+When pin numbers are displayed (key 'd'), internal connection groups are +written in square brackets, e.g. "2 [9]" means "pin 2, internally connected +to group 9". +

+Combined with the [nonetlist] patch, this +solves the "0-ohm 1206 jumper" problem: the element should be marked +as nonetlist, with both pins set intconn(1) - this will result in a 2 +pad element, pads internally connected, that can be part of any one network +without causing short. +

Example

+Crossing traces resolved using a 0 Ohm 1206 resistor called J1. The footprint +has an intconn between the two pads which resolves the final rat line. +

+ +

+ + + +

save/load and compatibility

+This patch introduces a new pin flag. In the following example +pin 2 and 4 are connected internally as group 9, while pin 3 +does not have any internal connections: +

+Pin[40000 60000 6000 3000 6600 2800 "2" "2" "square,intconn(9)"]
+Pin[40000 50000 6000 3000 6600 2800 "3" "3" "square"]
+Pin[40000 40000 6000 3000 6600 2800 "4" "4" "square,intconn(9)"]
+

+Mainline PCB will load the design ignoring internal connections - +this may introduce new rats. +

+Mainline PCB doesn't save intconn() and elements are embedded in the file - +once the design is loaded and saved with mainline PCB, internal connection +info is lost. + +

plans

+No plans - this feature is fully implemented. There is no plan for implementing +a GUI, internal connections should be hand-edited into the element. + + Index: trunk/doc-rnd/features/intconn1.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc-rnd/features/intconn1.png =================================================================== --- trunk/doc-rnd/features/intconn1.png (nonexistent) +++ trunk/doc-rnd/features/intconn1.png (revision 2495) Property changes on: trunk/doc-rnd/features/intconn1.png ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: trunk/doc-rnd/features/intconn2.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc-rnd/features/intconn2.png =================================================================== --- trunk/doc-rnd/features/intconn2.png (nonexistent) +++ trunk/doc-rnd/features/intconn2.png (revision 2495) Property changes on: trunk/doc-rnd/features/intconn2.png ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: trunk/doc-rnd/features/intconn3.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc-rnd/features/intconn3.png =================================================================== --- trunk/doc-rnd/features/intconn3.png (nonexistent) +++ trunk/doc-rnd/features/intconn3.png (revision 2495) Property changes on: trunk/doc-rnd/features/intconn3.png ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: trunk/doc-rnd/features/io.html =================================================================== --- trunk/doc-rnd/features/io.html (nonexistent) +++ trunk/doc-rnd/features/io.html (revision 2495) @@ -0,0 +1,23 @@ + + +

pcb-rnd - the [io_*] patches

+ +Mainline PCB core was coupled with the file format; the [io] patch set is +an effort to decouple any file design I/O from core. The original file format +(plain text .pcb and .fp) lives on as plugin called io_pcb. + +

+TODO + +

save/load and compatibility

+Not affected when io_pcb is used and .pcb or .fp files are loaded or saved. +

+Using other io_* implementations will obviously result in files that are +incompatible with mainline pcb (unless mainline pcb learns how to load those +formats). + +

plans

+The project is still in an early phase. + + + Index: trunk/doc-rnd/features/jumper_1206.fp =================================================================== --- trunk/doc-rnd/features/jumper_1206.fp (nonexistent) +++ trunk/doc-rnd/features/jumper_1206.fp (revision 2495) @@ -0,0 +1,7 @@ +Element["nonetlist" "1206 jumper, 0 ohm" "" "1206" 0 0 -3150 -3150 0 100 ""] +( + Pad[-5905 -1181 -5905 1181 5118 2000 5718 "1" "1" "square,intconn(1)"] + Pad[5905 -1181 5905 1181 5118 2000 5718 "2" "2" "square,intconn(1)"] + ElementLine[-2362 -3740 2362 -3740 800] + ElementLine[-2362 3740 2362 3740 800] +) Index: trunk/doc-rnd/features/library_t.html =================================================================== --- trunk/doc-rnd/features/library_t.html (nonexistent) +++ trunk/doc-rnd/features/library_t.html (revision 2495) @@ -0,0 +1,28 @@ + + +

pcb-rnd - the [library_t] patch

+ +The original code has a special setup for representing trees, C structures +called LibraryMenu and LibraryEntry. This system can represent only a subset +of trees: there is a root, a level consist of directories only and a next level, +each directory consist of data nodes only. This has been enough for newlib, +which strictly follows this model in the file system hierarchy. The lesstif +HID also hardwired this model in the GUI. +

+In pcb-rnd this has been replaced with a new struct type called library_t +that can represent an arbitrary tree: directories and files within directories +down to many levels. +

+Both the gtk and the lesstif had has been modified accordingly and can +properly display the tree. This in turn enables alternative footprint backend +implementations such as fp_wget to import +more complex libraries, e.g. the one on gedasymbols.org. + +

save/load and compatibility

+Not affected. + +

plans

+Finished, no plans. + + + Index: trunk/doc-rnd/features/mincut.html =================================================================== --- trunk/doc-rnd/features/mincut.html (nonexistent) +++ trunk/doc-rnd/features/mincut.html (revision 2495) @@ -0,0 +1,47 @@ + + +

pcb-rnd - the [mincut] patch

+ +The original code was highlighting pins/pads only when a short came around +after rats nest optimization. This was not very helpful on a complex board. +There had been a long discussion on the mailing list about the best solutions. +There were a few very good ideas, including: +

manual tagging of objects (lines, polys, arcs, vias) with net and warn + where two differently tagged net connects +
automatic tagging based on "where it was connected first", then the same + warning mechanism as above +
trace history (using the undo buffer?) and go back until when it was + not broken, check what exactly broke it +
history combined with tagging +
calculate minimal cut +

+I choose minimal cut for my patch because it doesn't require tracing the +full history or any manual administration of nets vs. objects (which I +would find inevitable even with manual tagging - directly or indirectly +the user needs to be able to change net tags). +

+The minimal cut is the least amount of object whose removal would resolve +the short. It is best demonstrated on an example: +

+ +

+Removing all the marked lines/polys/vias would surely resolve the short +(sometimes leaving rat lines behind). Minimal cut is better than randomly +removing objects, tho: it guarantees that the minimal amount of objects +are to be removed. On a complex board, this place is likely to be close +to the place where the problem really is - much closer than the pins/pads. +

+Since mincut can be expensive on large boards, the feature can be enabled +per board (a new PCB flag) and can be disbaled globally (--enable-mincut 0 +when starting PCB). + +

save/load and compatibility

+New PCB flag enablemincut. Mainline pcb ignores this flag but does not +preserve it. + +

plans

pcb-rnd - the [cycdrag] patches, negative box select

+ +When a selection is made using drag&drop (box selection), depending +on the direction the rule for object selection differ: +

drag from top-right towards bottom-left (positive sized box): + select objects that are fully contained in the box (original behaviour) +
drag from bottom-left towards top-right (negative sized box): + select objects that are even partially within the box or merely touch + the edge of the box +

+ +

save/load and compatibility

+Not affected. + +

plans

+Work more on some rough corners of the negative direction: e.g. pads are +handled as 0 width lines so the selection has to hit the center. + + + Index: trunk/doc-rnd/features/nonetlist.html =================================================================== --- trunk/doc-rnd/features/nonetlist.html (nonexistent) +++ trunk/doc-rnd/features/nonetlist.html (revision 2495) @@ -0,0 +1,53 @@ + + +

pcb-rnd - the [nonetlist] patch

+ +The [nonetlist] patch adds an element flag that makes PCB ignore the marked +element when dealing with netlists. This means connecting a net to a pin of +a nonetlist element will not cause a short. The refdes of a nonetlist +part is drawn with color element-color-nonetlist (ElementColor_nonetlist +in the source; default value #777777, grey). +

+Uses of the nonetlist feature: +

smd jumper: Combined with the [intconn] patch, this + solves the "0-ohm 1206 jumper" problem: the element should be marked + as nonetlist, with both pins set intconn(1) - this will result in a 2 + pad element, pads internally connected, that can be part of any one network + without causing short. +
mechanical parts that should not show up on the schematics: +
- mounting hole elements: single pin holes with silk marking the head of the screw +
- chassis (often with mounting holes or keep-out areas) +
- logos in footprints (no poly support in footprint - yet?) +
- mechanical parts which do not have solderable pins (plastic spacers, extra connector shields) +
- "spare parts", e.g. unused/disconnected DIP sockets or pin grids or connectors in a corner of the PCB for prototyping (dev-board style) +
+

+Preservation: gsch2pcb-rnd leaves nonetlist elements in the PCB. +

save/load and compatibility

+This patch introduces a new element flag. The following example demonstrates +a 1206 jumper footprint: +

+Element["nonetlist" "1206 jumper, 0 ohm" "" "1206" 0 0 -3150 -3150 0 100 ""]
+(
+	Pad[-5905 -1181 -5905 1181 5118 2000 5718 "1" "1" "square,intconn(1)"]
+	Pad[5905 -1181 5905 1181 5118 2000 5718 "2" "2" "square,intconn(1)"]
+	ElementLine[-2362 -3740 2362 -3740 800]
+	ElementLine[-2362 3740 2362 3740 800]
+)
+

+Mainline PCB will load the design ignoring internal connections and nonetlist +flag - this will cause shorts on all connected pins/pads and will break +the connection. +

+Mainline PCB doesn't save nonetlist and elements are embedded in the file - +once the design is loaded and saved with mainline PCB, the flag is lost. +After reloading the file in pcb-rnd, the element causes the same shorts +as in mainline PCB. + +

plans

+No plans, the feature is complete. + + Index: trunk/doc-rnd/features/onpoint.html =================================================================== --- trunk/doc-rnd/features/onpoint.html (nonexistent) +++ trunk/doc-rnd/features/onpoint.html (revision 2495) @@ -0,0 +1,50 @@ + + +

pcb-rnd - the [onpoint] patches

+ +Robert Drehmel writes: +

+When (e.g.) routing 5mm power traces on a small grid, it's not always easy to hit the
+point where the trace ended (which is the center of the semicircle at the end of the
+line) to start the next line.  If you have selected the line tool, finding the end of
+the line can become guesswork as the cursor doesn't change shape like it does with the
+select tool.
+I want my traces to consist of lines and arcs that are perfectly connected and I want
+to work as fast as possible.
+
+Attached is a small patch that
+
+  - makes it possible to deactivate snapping to "some sensible point along a line".
+    (that's what a comment in the code says). This snapping algorithm gets in the way
+    sometimes so you have to slowly go over a line to find out where it really ends,
+    bouncing back and forth between the points of the small grid, the end of the line
+    and these "sensible points", which is wasting time. The command is
+    "Display(ToggleSnapOffGridLine)". It is still activated by default to avoid
+    violating POLA.
+
+  - more importantly, introduces a new command called "Display(ToggleHighlightOnPoint)"
+    that highlights all lines and arcs which have (end)points exactly on the position
+    where the cross hair is currently snapped to. It therefore helps finding the end
+    points of lines and arcs, but sometimes also shows redundant traces, traces that
+    aren't perfectly connected to each other, traces that don't end directly on the
+    center of a via but should, etc. It works with thin draw too and I tested it with
+    gtk and lesstif.
+
+I use the second option mostly in conjunction with deactivating the first. Both commands
+have been added to the menu by means of (g)pcb-menu.res.in and are available as command
+line options as well.
+Caveats:
+  - The HID API expects all HIDs to make a copy of the color string when setting a color.
+  - The function that lightens up a color could be improved.
+  - I used it for a while, but after porting it from my local fork, it probably needs
+    more testing.
+

+ +

save/load and compatibility

+Not affected. + +

plans

+The feature is complete. + + + Index: trunk/doc-rnd/features/pcb-fp.html =================================================================== --- trunk/doc-rnd/features/pcb-fp.html (nonexistent) +++ trunk/doc-rnd/features/pcb-fp.html (revision 2495) @@ -0,0 +1,36 @@ + + +

pcb-rnd - the [pcb-fp] patch

+ +Pcb-fp is an effort to clean up the footprint situation: +

replace lib and newlib with pcblib, a library that tries to provide common footprints only +
clear the syntax: if a footprint name contains parenthesis, it's generated (parametric footprint), else it's the name of a static footprint file +
parametric footprints: replace m4 with a generic, language-independent footprint generator framework +
- implement libpcb_fp, which centralizes searching and loading footprints +
- fork gsch2pcb to gsch2pcb-rnd that uses libpcb_fp (and does not have any m4 references hardwired) +
- fork gnet_gsch2pcb.scm (the gnetlist backend) to remove m4 heuristics +
+

+ +

Example

+Intaractive parametric footprint selection in pcb-rnd: +

+ +

+An online footprint generator web1.0 version is also available. + +

save/load and compatibility

+Save/load files are not affected. If a schematics is written for the new +library and depends on parametric footprints: +

mainline gsch2pcb won't find those footprints +
mainline pcb won't show those footprints in the footprint selection dialog +

+ +

plans

+No plans - this feature is fully implemented. + + + Index: trunk/doc-rnd/features/pcb-fp.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc-rnd/features/pcb-fp.png =================================================================== --- trunk/doc-rnd/features/pcb-fp.png (nonexistent) +++ trunk/doc-rnd/features/pcb-fp.png (revision 2495) Property changes on: trunk/doc-rnd/features/pcb-fp.png ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: trunk/doc-rnd/features/pcblib.html =================================================================== --- trunk/doc-rnd/features/pcblib.html (nonexistent) +++ trunk/doc-rnd/features/pcblib.html (revision 2495) @@ -0,0 +1,56 @@ + + +

pcb-rnd - the [pcblib] and [pcblib-param] and [fp_fs] patches

+ +

+The footprint library shipped with mainline pcb is cluttered with +special puprose parts. I believe PCB encourages the user from +an early stage to build his own library. Thus the purpose of +the library shipped with PCB should be +to provide a minimal collection of real essential footprints ... +

... for the very beginning of the learning curve; +
... and to be the core of the user's own library later. +

+[pcblib] is a replacement of newlib/ and lib/ and the m4 macros with +such an essential core library of static footprints ("file elements") +and easier-to-use parametric footprints. +

+There is an online map of +the library and +an online interface to the parametric footprint generators. + +

Design decisions

+Parts are sorted only in a few directories: smd, tru-hole, connector and +parametric. I believe there are so many orthogonal properties of footpritns +that there's no obvious hierarchy. Also, pcblib contains much fewer footpritns +than newlib so it should be still easy to navigate. +

+Parametric footprints are in a separate directory for now, even tho they +would fit under smd, tru-hole or connector. The reason is purely historical +and the layout may change in the future. + +

Example

+To the right: Footprint selection dialog on pcblib, with the smd directory +open. Note how few smd parts are there. Still, smd/ is the most crowded +subdirectory! + +

[fp_fs]

+As of vesion 1.0.10, the footprint list/search/load of footprints is a plugin. +The original code that handles local file system footprint libraries (e.g. +pcblib or newlib) is now a plugin. Altnerative plugins can be provided that work +from databases or from the web. In extreme +situations the file system based footprint plugin can even be disabled. + +

save/load and compatibility

+Not affected: elements are embedded in the PCB. + +

plans

+None, the feature is complete. +

+ + Index: trunk/doc-rnd/features/pcblib.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc-rnd/features/pcblib.png =================================================================== --- trunk/doc-rnd/features/pcblib.png (nonexistent) +++ trunk/doc-rnd/features/pcblib.png (revision 2495) Property changes on: trunk/doc-rnd/features/pcblib.png ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: trunk/doc-rnd/features/polygrid.html =================================================================== --- trunk/doc-rnd/features/polygrid.html (nonexistent) +++ trunk/doc-rnd/features/polygrid.html (revision 2495) @@ -0,0 +1,17 @@ + + +

pcb-rnd - the [polygrid] patch

+ +Polygrid adds an option to the ps exporter to fill polygons with a grid +of horizontal and vertical lines instead of full fill. When toner transfer +is used or test prints are produced, the grid may save some toner. + +

save/load and compatibility

+Not affected. + +

plans

+Fix bugs. +

+No (feature) plans - this feature is fully implemented. + + Index: trunk/doc-rnd/features/res.html =================================================================== --- trunk/doc-rnd/features/res.html (nonexistent) +++ trunk/doc-rnd/features/res.html (revision 2495) @@ -0,0 +1,129 @@ + + +

pcb-rnd - the [res] patch

+ +PCB used to have an own file format for describing resources (menu structure +and hotkey bindings, vendor drill mapping). The resource format was generic +enough to describe these things, but the syntax was somewhat wierd: mixed +positional and named fields. More precisely, composite nodes could contain +named and anonymous subnodes, and the meaning of anonymous subnodes depended +on their position in the anon-subnode-list. +

+The code that dealt with the in-memory representation of the resource tree +was wierd and big chunks duplicated in the HIDs and vendor drill module. It +was also hard to parse a resource file with external tools. +

+Since version 1.0.10, pcb-rnd replaces resource files with +lihata. Lihata is a small, generic +purpose container format that can describe arbitrary trees. Just like resource +file syntax, lihata is optimized for hand-editing: no need to use excess +quoting or long boilerplate blocks. +

+Liblihata also provides a lot of helper functions that made the code +dealing with the menus and vendor drill resources much simpler and less +redundant. Since the parser is small and external, and since there are +external converter tools available, it is also easier to deal with the +files outside of the pcb executable. + +

menu files

+There are pcb-menu-gtk.lht and pcb-menu-lesstif.lht. They are in trunk/src +in the source tree and are instaslled in the SHAREDIR. Currently each GUI +HID (lesstif, gtk) loads the corresponding menu file. + +

menu resource lihata structure

+The root of a menu resource file should be a ha: with the following +children: +

li:mouse for mouse button bindings +
li:main_menu for describing the main menu +
li:popups for describing the popup menus +

+All children are optional, but recommended. Thus the file stucture, zoomed +out, is: +

+ha:{
+	li:mouse { ... }
+	li:main_menu { ... }
+	li:popups { ... }
+}
+

+ +

li:mouse

+The mouse subtree may contain a li: for each mouse button action; +the children of the list are further li: nodes for key modifiers, whose +children are text nodes: actions executed in order. +

+Buttons supported are: left, right, middle, up, down - the last two +are for the scroll wheel. Modifier name should start with "press" or "release" +optionally followed by modifier key suffixes separated with dashes, e.g. +"press-alt-shift" means the given button is pressed while alt and shift +were also pressed. +

+Example structure: +

+	li:mouse {
+		li:left {
+			li:press            = { Mode(Notify) }
+			li:press-ctrl       = { Mode(Save); Mode(None); }
+		}
+	}
+

+ +

li:main_menu

+The main menu is a list of menubar items that may host submenu items +recursively. Each normal item is a hash with the following children: +

li:submenu an ordered list of submenu nodes (should not have accel key or action) +
tip tooltip text +
action text or list of actions to execute when menu is selected +
a a key description for an accelerator key (hotkey) +
li:a a list of key descriptions for an accelerator keys (hotkeys); all keys will be bound to the menu and the first key is shown in the menu +

+Special menu items are text nodes instead of hashes; they are: +

starting with @, are dynamic, auto-generated items (e.g. layers; might be HID-dependent) +
a singel dash: separator +

+A key description is a text in the form of: +

the name of the node is the visible name of the menu item +
<key>keyname, e.g. "<key>k" for key K, or "<key>F10" for F10 +
modifier<key>keyname, e.g. "Alt-<key>K" for Alt+K +
modifier-modifier<key>keyname, e.g. "Shift-Alt-<key>K" for Shift+Alt+K; modifiers are Alt, Shift and Ctrl; order does not matter, all three can be used together. +
multikey sequence: multiple of the above, separated by semicolons (protected with {} for lihata, as the text contains semicolon); e.g. "{<key>f;<key>o}" means the user presses "f" then "o". Sequences can be a dozen stroke long and any segment may use modifiers +

+ +An example menu item with submenus (can be a main menu or a submenu of +another menu item): +

+ha:example menu item {
+	li:submenu {
+		ha:menu item {
+			action=Save(ElementConnections)
+			tip=example menu
+		}
+		-
+		ha:another menu item {
+			a={Shift-Alt<key>r}
+			action={Action1(); Action2();}
+		}
+	}
+}
+

+ +

li:popups

+Each children is a hash that describes a popup menu. A popup menu behaves +exactly like a menu item, it should have a submenu list. Popup windows will +be popped up by executing an action with the name of the popup menu. + +

save/load and compatibility

+Not affected. + +

plans

+The resource file format conversion is done. There are other parts of the code +that will probably get lihata instead of the current custom parsers, e.g. +the preferences/settings file. + + + Index: trunk/doc-rnd/features/scconfig.html =================================================================== --- trunk/doc-rnd/features/scconfig.html (nonexistent) +++ trunk/doc-rnd/features/scconfig.html (revision 2495) @@ -0,0 +1,15 @@ + + +

pcb-rnd - the [scconfig] patch

+ +Pcb-rnd uses scconfig +for ./configure instead of autotools. Scconfig is smaller and easier +to maintain. + +

save/load and compatibility

+Not affected. + +

plans

+No plans - this feature is fully implemented by now. + + Index: trunk/doc-rnd/features/settings.html =================================================================== --- trunk/doc-rnd/features/settings.html (nonexistent) +++ trunk/doc-rnd/features/settings.html (revision 2495) @@ -0,0 +1,31 @@ + + +

pcb-rnd - settings

+ +There are a few minor changes in default settings compared to mainline +pcb. + + + + + +

name +	description +	where to change + +
layers +	the default layer stack is optimized for two sided boards with 3 layers on both sides +	edit or replace /usr/share/pcb-rnd/default.pcb + +
styles & DRC +	default styles and DRC settings are optimized for toner transfer +	edit or replace /usr/share/pcb-rnd/default.pcb + +
grid +	on startup "enable visible grid" is on and grid is set to 25 mil +	grep "SET.* grid" main.c + +

+ + + Index: trunk/doc-rnd/features/square.html =================================================================== --- trunk/doc-rnd/features/square.html (nonexistent) +++ trunk/doc-rnd/features/square.html (revision 2495) @@ -0,0 +1,71 @@ + + +

pcb-rnd - the [square] patch

+Most of my PCBs end up in toner transfer. There are a lot +of tricks around prototyping at home. One of the problems I often +face is small rings peeling off during rework (and rework tend to +happen on the first prototypes). The solution for this is increasing +ring size - which is not suitable if traces are passing between pins. +Another solution is to increase the area of the pin: +

square pin: while it makes the pin slightly larger still letting traces pass between pins, it's too symmetrical and can not use up extra room +
DJ's teardrop plugin: this increases the area only toward the trace, whereas very often there's more room on the opposite side +
manually add an extra poly around the pin; with multiple pins it's hard to get the polys separate +
manually add a short extra track on the pin, width matching the size of the pin; this is very close, but increases workload when components are moved, layers are changed +

+The patch takes an octagon pin and stretches points in various directions. +There are 4 bits (for left, right, up and down) to indicate in which directions +the stretch applies. Pressing 'q' on a pin cycles thru round pin, square pin, +16 stretched octagons and the original octagon. +

+The code is also patched to handle clearances, shorts and connections (find.c). +

+Thermals are not fully working for funny shaped pins, but it has low priority: +they still work fine for rounded and square pins and if there is a poly around +the pin, I wouldn't use shaped pins anyway. + +

save/load and compatibility

+This patch introduces a new pin flag called shape(n), where n is an integer +selecting the shape of the pin when the square flag is also set: +

+Pin[40000 60000 6000 3000 6600 2800 "8" "8" "square,shape(3)"]
+

+Mainline PCB will load the design ignoring the custom shape and will use a +square pin. As long a traces end in the center point of the pin, this +should not break connections. +

+Mainline PCB doesn't save shape() - once the design is loaded and saved with +mainline PCB pin shape info is lost. + +

plans

+In the original code there are separate code paths for round, octagonal and +square pins. The separation repeats for at least: +

drawing the pin shape +
calculating the clearance +
checking whether things overlap or connect (pin vs pin, pin vs line, etc.) +
autorouter +

+In most cases a set of hardwired constants are written in the C code. A notable +exception was the octagon pin draw function, that had x and y offsets in a const +table for 8 points and a loop to create the poly (or line segments in thin draw). +

+The [square] feature is a good base for cleaning up the code a bit and for +moving toward a generic pin shape patch: +

hardwired octagon calculations should be replaced to use the same x;y const offset table +
the table should be replaced by a struct that describes length (number of points) - alternatively use POLYAREA +
square pin should be renamed to polygon pin +
octagon flag shall be removed - it should be a configuration of the x;y const table +
square flag shall be removed - it should be a configuration +
the only flag remaining should be shape(); if a pin is not shaped, it's round +
the pin shape struct should have a field for compatibility - to mark the entry corresponding to the original square and octagon pins so PCB-rnd format can be converted to and from the mainline PCB format. +
there should be a set of pin shapes in a default configuration table, including square and octagonal; these should be static +
the PCB file format should be extended with an option to expand the pin shape table with custom shapes +
UI: shapes could be imported (converted) from polys around vias +
UI: since there may be a lot of pin shapes, a GUI selector alternative shall be offered while also keeping the cycle-thru 'q' key +

+ + Index: trunk/doc-rnd/features/square.pcb =================================================================== --- trunk/doc-rnd/features/square.pcb (nonexistent) +++ trunk/doc-rnd/features/square.pcb (revision 2495) @@ -0,0 +1,893 @@ +# release: pcb 20110918 + +# To read pcb files, the pcb version (or the git source date) must be >= the file version +FileVersion[20070407] + +PCB["" 130000 105000] + +Grid[2500.0 0 0 1] +Cursor[0 0 0.000000] +PolyArea[3100.006200] +Thermal[0.500000] +DRC[1000 1000 1000 1000 1500 1000] +Flags("nameonpcb,uniquename,clearnew") +Groups("1,c:2,s:3:4:5:6:7:8") +Styles["Signal,1500,6000,3150,2500:Power,3000,6000,3937,2500:Fat,8000,6000,3500,2500:Skinny,1200,2402,1181,2500"] + +Symbol[' ' 1800] +( +) +Symbol['!' 1200] +( + SymbolLine[0 4500 0 5000 800] + SymbolLine[0 1000 0 3500 800] +) +Symbol['"' 1200] +( + SymbolLine[0 1000 0 2000 800] + SymbolLine[1000 1000 1000 2000 800] +) +Symbol['#' 1200] +( + SymbolLine[0 3500 2000 3500 800] + SymbolLine[0 2500 2000 2500 800] + SymbolLine[1500 2000 1500 4000 800] + SymbolLine[500 2000 500 4000 800] +) +Symbol['$' 1200] +( + SymbolLine[1500 1500 2000 2000 800] + SymbolLine[500 1500 1500 1500 800] + SymbolLine[0 2000 500 1500 800] + SymbolLine[0 2000 0 2500 800] + SymbolLine[0 2500 500 3000 800] + SymbolLine[500 3000 1500 3000 800] + SymbolLine[1500 3000 2000 3500 800] + SymbolLine[2000 3500 2000 4000 800] + SymbolLine[1500 4500 2000 4000 800] + SymbolLine[500 4500 1500 4500 800] + SymbolLine[0 4000 500 4500 800] + SymbolLine[1000 1000 1000 5000 800] +) +Symbol['%' 1200] +( + SymbolLine[0 1500 0 2000 800] + SymbolLine[0 1500 500 1000 800] + SymbolLine[500 1000 1000 1000 800] + SymbolLine[1000 1000 1500 1500 800] + SymbolLine[1500 1500 1500 2000 800] + SymbolLine[1000 2500 1500 2000 800] + SymbolLine[500 2500 1000 2500 800] + SymbolLine[0 2000 500 2500 800] + SymbolLine[0 5000 4000 1000 800] + SymbolLine[3500 5000 4000 4500 800] + SymbolLine[4000 4000 4000 4500 800] + SymbolLine[3500 3500 4000 4000 800] + SymbolLine[3000 3500 3500 3500 800] + SymbolLine[2500 4000 3000 3500 800] + SymbolLine[2500 4000 2500 4500 800] + SymbolLine[2500 4500 3000 5000 800] + SymbolLine[3000 5000 3500 5000 800] +) +Symbol['&' 1200] +( + SymbolLine[0 4500 500 5000 800] + SymbolLine[0 1500 0 2500 800] + SymbolLine[0 1500 500 1000 800] + SymbolLine[0 3500 1500 2000 800] + SymbolLine[500 5000 1000 5000 800] + SymbolLine[1000 5000 2000 4000 800] + SymbolLine[0 2500 2500 5000 800] + SymbolLine[500 1000 1000 1000 800] + SymbolLine[1000 1000 1500 1500 800] + SymbolLine[1500 1500 1500 2000 800] + SymbolLine[0 3500 0 4500 800] +) +Symbol[''' 1200] +( + SymbolLine[0 2000 1000 1000 800] +) +Symbol['(' 1200] +( + SymbolLine[0 4500 500 5000 800] + SymbolLine[0 1500 500 1000 800] + SymbolLine[0 1500 0 4500 800] +) +Symbol[')' 1200] +( + SymbolLine[0 1000 500 1500 800] + SymbolLine[500 1500 500 4500 800] + SymbolLine[0 5000 500 4500 800] +) +Symbol['*' 1200] +( + SymbolLine[0 2000 2000 4000 800] + SymbolLine[0 4000 2000 2000 800] + SymbolLine[0 3000 2000 3000 800] + SymbolLine[1000 2000 1000 4000 800] +) +Symbol['+' 1200] +( + SymbolLine[0 3000 2000 3000 800] + SymbolLine[1000 2000 1000 4000 800] +) +Symbol[',' 1200] +( + SymbolLine[0 6000 1000 5000 800] +) +Symbol['-' 1200] +( + SymbolLine[0 3000 2000 3000 800] +) +Symbol['.' 1200] +( + SymbolLine[0 5000 500 5000 800] +) +Symbol['/' 1200] +( + SymbolLine[0 4500 3000 1500 800] +) +Symbol['0' 1200] +( + SymbolLine[0 4500 500 5000 800] + SymbolLine[0 1500 0 4500 800] + SymbolLine[0 1500 500 1000 800] + SymbolLine[500 1000 1500 1000 800] + SymbolLine[1500 1000 2000 1500 800] + SymbolLine[2000 1500 2000 4500 800] + SymbolLine[1500 5000 2000 4500 800] + SymbolLine[500 5000 1500 5000 800] + SymbolLine[0 4000 2000 2000 800] +) +Symbol['1' 1200] +( + SymbolLine[0 1800 800 1000 800] + SymbolLine[800 1000 800 5000 800] + SymbolLine[0 5000 1500 5000 800] +) +Symbol['2' 1200] +( + SymbolLine[0 1500 500 1000 800] + SymbolLine[500 1000 2000 1000 800] + SymbolLine[2000 1000 2500 1500 800] + SymbolLine[2500 1500 2500 2500 800] + SymbolLine[0 5000 2500 2500 800] + SymbolLine[0 5000 2500 5000 800] +) +Symbol['3' 1200] +( + SymbolLine[0 1500 500 1000 800] + SymbolLine[500 1000 1500 1000 800] + SymbolLine[1500 1000 2000 1500 800] + SymbolLine[1500 5000 2000 4500 800] + SymbolLine[500 5000 1500 5000 800] + SymbolLine[0 4500 500 5000 800] + SymbolLine[500 2800 1500 2800 800] + SymbolLine[2000 1500 2000 2300 800] + SymbolLine[2000 3300 2000 4500 800] + SymbolLine[2000 3300 1500 2800 800] + SymbolLine[2000 2300 1500 2800 800] +) +Symbol['4' 1200] +( + SymbolLine[0 3500 2000 1000 800] + SymbolLine[0 3500 2500 3500 800] + SymbolLine[2000 1000 2000 5000 800] +) +Symbol['5' 1200] +( + SymbolLine[0 1000 2000 1000 800] + SymbolLine[0 1000 0 3000 800] + SymbolLine[0 3000 500 2500 800] + SymbolLine[500 2500 1500 2500 800] + SymbolLine[1500 2500 2000 3000 800] + SymbolLine[2000 3000 2000 4500 800] + SymbolLine[1500 5000 2000 4500 800] + SymbolLine[500 5000 1500 5000 800] + SymbolLine[0 4500 500 5000 800] +) +Symbol['6' 1200] +( + SymbolLine[1500 1000 2000 1500 800] + SymbolLine[500 1000 1500 1000 800] + SymbolLine[0 1500 500 1000 800] + SymbolLine[0 1500 0 4500 800] + SymbolLine[0 4500 500 5000 800] + SymbolLine[1500 2800 2000 3300 800] + SymbolLine[0 2800 1500 2800 800] + SymbolLine[500 5000 1500 5000 800] + SymbolLine[1500 5000 2000 4500 800] + SymbolLine[2000 3300 2000 4500 800] +) +Symbol['7' 1200] +( + SymbolLine[500 5000 2500 1000 800] + SymbolLine[0 1000 2500 1000 800] +) +Symbol['8' 1200] +( + SymbolLine[0 4500 500 5000 800] + SymbolLine[0 3700 0 4500 800] + SymbolLine[0 3700 700 3000 800] + SymbolLine[700 3000 1300 3000 800] + SymbolLine[1300 3000 2000 3700 800] + SymbolLine[2000 3700 2000 4500 800] + SymbolLine[1500 5000 2000 4500 800] + SymbolLine[500 5000 1500 5000 800] + SymbolLine[0 2300 700 3000 800] + SymbolLine[0 1500 0 2300 800] + SymbolLine[0 1500 500 1000 800] + SymbolLine[500 1000 1500 1000 800] + SymbolLine[1500 1000 2000 1500 800] + SymbolLine[2000 1500 2000 2300 800] + SymbolLine[1300 3000 2000 2300 800] +) +Symbol['9' 1200] +( + SymbolLine[500 5000 2000 3000 800] + SymbolLine[2000 1500 2000 3000 800] + SymbolLine[1500 1000 2000 1500 800] + SymbolLine[500 1000 1500 1000 800] + SymbolLine[0 1500 500 1000 800] + SymbolLine[0 1500 0 2500 800] + SymbolLine[0 2500 500 3000 800] + SymbolLine[500 3000 2000 3000 800] +) +Symbol[':' 1200] +( + SymbolLine[0 2500 500 2500 800] + SymbolLine[0 3500 500 3500 800] +) +Symbol[';' 1200] +( + SymbolLine[0 5000 1000 4000 800] + SymbolLine[1000 2500 1000 3000 800] +) +Symbol['<' 1200] +( + SymbolLine[0 3000 1000 2000 800] + SymbolLine[0 3000 1000 4000 800] +) +Symbol['=' 1200] +( + SymbolLine[0 2500 2000 2500 800] + SymbolLine[0 3500 2000 3500 800] +) +Symbol['>' 1200] +( + SymbolLine[0 2000 1000 3000 800] + SymbolLine[0 4000 1000 3000 800] +) +Symbol['?' 1200] +( + SymbolLine[1000 3000 1000 3500 800] + SymbolLine[1000 4500 1000 5000 800] + SymbolLine[0 1500 0 2000 800] + SymbolLine[0 1500 500 1000 800] + SymbolLine[500 1000 1500 1000 800] + SymbolLine[1500 1000 2000 1500 800] + SymbolLine[2000 1500 2000 2000 800] + SymbolLine[1000 3000 2000 2000 800] +) +Symbol['@' 1200] +( + SymbolLine[0 1000 0 4000 800] + SymbolLine[0 4000 1000 5000 800] + SymbolLine[1000 5000 4000 5000 800] + SymbolLine[5000 3500 5000 1000 800] + SymbolLine[5000 1000 4000 0 800] + SymbolLine[4000 0 1000 0 800] + SymbolLine[1000 0 0 1000 800] + SymbolLine[1500 2000 1500 3000 800] + SymbolLine[1500 3000 2000 3500 800] + SymbolLine[2000 3500 3000 3500 800] + SymbolLine[3000 3500 3500 3000 800] + SymbolLine[3500 3000 4000 3500 800] + SymbolLine[3500 3000 3500 1500 800] + SymbolLine[3500 2000 3000 1500 800] + SymbolLine[2000 1500 3000 1500 800] + SymbolLine[2000 1500 1500 2000 800] + SymbolLine[4000 3500 5000 3500 800] +) +Symbol['A' 1200] +( + SymbolLine[0 2000 0 5000 800] + SymbolLine[0 2000 700 1000 800] + SymbolLine[700 1000 1800 1000 800] + SymbolLine[1800 1000 2500 2000 800] + SymbolLine[2500 2000 2500 5000 800] + SymbolLine[0 3000 2500 3000 800] +) +Symbol['B' 1200] +( + SymbolLine[0 5000 2000 5000 800] + SymbolLine[2000 5000 2500 4500 800] + SymbolLine[2500 3300 2500 4500 800] + SymbolLine[2000 2800 2500 3300 800] + SymbolLine[500 2800 2000 2800 800] + SymbolLine[500 1000 500 5000 800] + SymbolLine[0 1000 2000 1000 800] + SymbolLine[2000 1000 2500 1500 800] + SymbolLine[2500 1500 2500 2300 800] + SymbolLine[2000 2800 2500 2300 800] +) +Symbol['C' 1200] +( + SymbolLine[700 5000 2000 5000 800] + SymbolLine[0 4300 700 5000 800] + SymbolLine[0 1700 0 4300 800] + SymbolLine[0 1700 700 1000 800] + SymbolLine[700 1000 2000 1000 800] +) +Symbol['D' 1200] +( + SymbolLine[500 1000 500 5000 800] + SymbolLine[1800 1000 2500 1700 800] + SymbolLine[2500 1700 2500 4300 800] + SymbolLine[1800 5000 2500 4300 800] + SymbolLine[0 5000 1800 5000 800] + SymbolLine[0 1000 1800 1000 800] +) +Symbol['E' 1200] +( + SymbolLine[0 2800 1500 2800 800] + SymbolLine[0 5000 2000 5000 800] + SymbolLine[0 1000 0 5000 800] + SymbolLine[0 1000 2000 1000 800] +) +Symbol['F' 1200] +( + SymbolLine[0 1000 0 5000 800] + SymbolLine[0 1000 2000 1000 800] + SymbolLine[0 2800 1500 2800 800] +) +Symbol['G' 1200] +( + SymbolLine[2000 1000 2500 1500 800] + SymbolLine[500 1000 2000 1000 800] + SymbolLine[0 1500 500 1000 800] + SymbolLine[0 1500 0 4500 800] + SymbolLine[0 4500 500 5000 800] + SymbolLine[500 5000 2000 5000 800] + SymbolLine[2000 5000 2500 4500 800] + SymbolLine[2500 3500 2500 4500 800] + SymbolLine[2000 3000 2500 3500 800] + SymbolLine[1000 3000 2000 3000 800] +) +Symbol['H' 1200] +( + SymbolLine[0 1000 0 5000 800] + SymbolLine[2500 1000 2500 5000 800] + SymbolLine[0 3000 2500 3000 800] +) +Symbol['I' 1200] +( + SymbolLine[0 1000 1000 1000 800] + SymbolLine[500 1000 500 5000 800] + SymbolLine[0 5000 1000 5000 800] +) +Symbol['J' 1200] +( + SymbolLine[700 1000 1500 1000 800] + SymbolLine[1500 1000 1500 4500 800] + SymbolLine[1000 5000 1500 4500 800] + SymbolLine[500 5000 1000 5000 800] + SymbolLine[0 4500 500 5000 800] + SymbolLine[0 4500 0 4000 800] +) +Symbol['K' 1200] +( + SymbolLine[0 1000 0 5000 800] + SymbolLine[0 3000 2000 1000 800] + SymbolLine[0 3000 2000 5000 800] +) +Symbol['L' 1200] +( + SymbolLine[0 1000 0 5000 800] + SymbolLine[0 5000 2000 5000 800] +) +Symbol['M' 1200] +( + SymbolLine[0 1000 0 5000 800] + SymbolLine[0 1000 1500 3000 800] + SymbolLine[1500 3000 3000 1000 800] + SymbolLine[3000 1000 3000 5000 800] +) +Symbol['N' 1200] +( + SymbolLine[0 1000 0 5000 800] + SymbolLine[0 1000 2500 5000 800] + SymbolLine[2500 1000 2500 5000 800] +) +Symbol['O' 1200] +( + SymbolLine[0 1500 0 4500 800] + SymbolLine[0 1500 500 1000 800] + SymbolLine[500 1000 1500 1000 800] + SymbolLine[1500 1000 2000 1500 800] + SymbolLine[2000 1500 2000 4500 800] + SymbolLine[1500 5000 2000 4500 800] + SymbolLine[500 5000 1500 5000 800] + SymbolLine[0 4500 500 5000 800] +) +Symbol['P' 1200] +( + SymbolLine[500 1000 500 5000 800] + SymbolLine[0 1000 2000 1000 800] + SymbolLine[2000 1000 2500 1500 800] + SymbolLine[2500 1500 2500 2500 800] + SymbolLine[2000 3000 2500 2500 800] + SymbolLine[500 3000 2000 3000 800] +) +Symbol['Q' 1200] +( + SymbolLine[0 1500 0 4500 800] + SymbolLine[0 1500 500 1000 800] + SymbolLine[500 1000 1500 1000 800] + SymbolLine[1500 1000 2000 1500 800] + SymbolLine[2000 1500 2000 4000 800] + SymbolLine[1000 5000 2000 4000 800] + SymbolLine[500 5000 1000 5000 800] + SymbolLine[0 4500 500 5000 800] + SymbolLine[1000 3500 2000 5000 800] +) +Symbol['R' 1200] +( + SymbolLine[0 1000 2000 1000 800] + SymbolLine[2000 1000 2500 1500 800] + SymbolLine[2500 1500 2500 2500 800] + SymbolLine[2000 3000 2500 2500 800] + SymbolLine[500 3000 2000 3000 800] + SymbolLine[500 1000 500 5000 800] + SymbolLine[1300 3000 2500 5000 800] +) +Symbol['S' 1200] +( + SymbolLine[2000 1000 2500 1500 800] + SymbolLine[500 1000 2000 1000 800] + SymbolLine[0 1500 500 1000 800] + SymbolLine[0 1500 0 2500 800] + SymbolLine[0 2500 500 3000 800] + SymbolLine[500 3000 2000 3000 800] + SymbolLine[2000 3000 2500 3500 800] + SymbolLine[2500 3500 2500 4500 800] + SymbolLine[2000 5000 2500 4500 800] + SymbolLine[500 5000 2000 5000 800] + SymbolLine[0 4500 500 5000 800] +) +Symbol['T' 1200] +( + SymbolLine[0 1000 2000 1000 800] + SymbolLine[1000 1000 1000 5000 800] +) +Symbol['U' 1200] +( + SymbolLine[0 1000 0 4500 800] + SymbolLine[0 4500 500 5000 800] + SymbolLine[500 5000 1500 5000 800] + SymbolLine[1500 5000 2000 4500 800] + SymbolLine[2000 1000 2000 4500 800] +) +Symbol['V' 1200] +( + SymbolLine[0 1000 1000 5000 800] + SymbolLine[1000 5000 2000 1000 800] +) +Symbol['W' 1200] +( + SymbolLine[0 1000 0 3000 800] + SymbolLine[0 3000 500 5000 800] + SymbolLine[500 5000 1500 3000 800] + SymbolLine[1500 3000 2500 5000 800] + SymbolLine[2500 5000 3000 3000 800] + SymbolLine[3000 3000 3000 1000 800] +) +Symbol['X' 1200] +( + SymbolLine[0 5000 2500 1000 800] + SymbolLine[0 1000 2500 5000 800] +) +Symbol['Y' 1200] +( + SymbolLine[0 1000 1000 3000 800] + SymbolLine[1000 3000 2000 1000 800] + SymbolLine[1000 3000 1000 5000 800] +) +Symbol['Z' 1200] +( + SymbolLine[0 1000 2500 1000 800] + SymbolLine[0 5000 2500 1000 800] + SymbolLine[0 5000 2500 5000 800] +) +Symbol['[' 1200] +( + SymbolLine[0 1000 500 1000 800] + SymbolLine[0 1000 0 5000 800] + SymbolLine[0 5000 500 5000 800] +) +Symbol['\' 1200] +( + SymbolLine[0 1500 3000 4500 800] +) +Symbol[']' 1200] +( + SymbolLine[0 1000 500 1000 800] + SymbolLine[500 1000 500 5000 800] + SymbolLine[0 5000 500 5000 800] +) +Symbol['^' 1200] +( + SymbolLine[0 1500 500 1000 800] + SymbolLine[500 1000 1000 1500 800] +) +Symbol['_' 1200] +( + SymbolLine[0 5000 2000 5000 800] +) +Symbol['a' 1200] +( + SymbolLine[1500 3000 2000 3500 800] + SymbolLine[500 3000 1500 3000 800] + SymbolLine[0 3500 500 3000 800] + SymbolLine[0 3500 0 4500 800] + SymbolLine[0 4500 500 5000 800] + SymbolLine[2000 3000 2000 4500 800] + SymbolLine[2000 4500 2500 5000 800] + SymbolLine[500 5000 1500 5000 800] + SymbolLine[1500 5000 2000 4500 800] +) +Symbol['b' 1200] +( + SymbolLine[0 1000 0 5000 800] + SymbolLine[0 4500 500 5000 800] + SymbolLine[500 5000 1500 5000 800] + SymbolLine[1500 5000 2000 4500 800] + SymbolLine[2000 3500 2000 4500 800] + SymbolLine[1500 3000 2000 3500 800] + SymbolLine[500 3000 1500 3000 800] + SymbolLine[0 3500 500 3000 800] +) +Symbol['c' 1200] +( + SymbolLine[500 3000 2000 3000 800] + SymbolLine[0 3500 500 3000 800] + SymbolLine[0 3500 0 4500 800] + SymbolLine[0 4500 500 5000 800] + SymbolLine[500 5000 2000 5000 800] +) +Symbol['d' 1200] +( + SymbolLine[2000 1000 2000 5000 800] + SymbolLine[1500 5000 2000 4500 800] + SymbolLine[500 5000 1500 5000 800] + SymbolLine[0 4500 500 5000 800] + SymbolLine[0 3500 0 4500 800] + SymbolLine[0 3500 500 3000 800] + SymbolLine[500 3000 1500 3000 800] + SymbolLine[1500 3000 2000 3500 800] +) +Symbol['e' 1200] +( + SymbolLine[500 5000 2000 5000 800] + SymbolLine[0 4500 500 5000 800] + SymbolLine[0 3500 0 4500 800] + SymbolLine[0 3500 500 3000 800] + SymbolLine[500 3000 1500 3000 800] + SymbolLine[1500 3000 2000 3500 800] + SymbolLine[0 4000 2000 4000 800] + SymbolLine[2000 4000 2000 3500 800] +) +Symbol['f' 1000] +( + SymbolLine[500 1500 500 5000 800] + SymbolLine[500 1500 1000 1000 800] + SymbolLine[1000 1000 1500 1000 800] + SymbolLine[0 3000 1000 3000 800] +) +Symbol['g' 1200] +( + SymbolLine[1500 3000 2000 3500 800] + SymbolLine[500 3000 1500 3000 800] + SymbolLine[0 3500 500 3000 800] + SymbolLine[0 3500 0 4500 800] + SymbolLine[0 4500 500 5000 800] + SymbolLine[500 5000 1500 5000 800] + SymbolLine[1500 5000 2000 4500 800] + SymbolLine[0 6000 500 6500 800] + SymbolLine[500 6500 1500 6500 800] + SymbolLine[1500 6500 2000 6000 800] + SymbolLine[2000 3000 2000 6000 800] +) +Symbol['h' 1200] +( + SymbolLine[0 1000 0 5000 800] + SymbolLine[0 3500 500 3000 800] + SymbolLine[500 3000 1500 3000 800] + SymbolLine[1500 3000 2000 3500 800] + SymbolLine[2000 3500 2000 5000 800] +) +Symbol['i' 1000] +( + SymbolLine[0 2000 0 2100 1000] + SymbolLine[0 3500 0 5000 800] +) +Symbol['j' 1000] +( + SymbolLine[500 2000 500 2100 1000] + SymbolLine[500 3500 500 6000 800] + SymbolLine[0 6500 500 6000 800] +) +Symbol['k' 1200] +( + SymbolLine[0 1000 0 5000 800] + SymbolLine[0 3500 1500 5000 800] + SymbolLine[0 3500 1000 2500 800] +) +Symbol['l' 1000] +( + SymbolLine[0 1000 0 4500 800] + SymbolLine[0 4500 500 5000 800] +) +Symbol['m' 1200] +( + SymbolLine[500 3500 500 5000 800] + SymbolLine[500 3500 1000 3000 800] + SymbolLine[1000 3000 1500 3000 800] + SymbolLine[1500 3000 2000 3500 800] + SymbolLine[2000 3500 2000 5000 800] + SymbolLine[2000 3500 2500 3000 800] + SymbolLine[2500 3000 3000 3000 800] + SymbolLine[3000 3000 3500 3500 800] + SymbolLine[3500 3500 3500 5000 800] + SymbolLine[0 3000 500 3500 800] +) +Symbol['n' 1200] +( + SymbolLine[500 3500 500 5000 800] + SymbolLine[500 3500 1000 3000 800] + SymbolLine[1000 3000 1500 3000 800] + SymbolLine[1500 3000 2000 3500 800] + SymbolLine[2000 3500 2000 5000 800] + SymbolLine[0 3000 500 3500 800] +) +Symbol['o' 1200] +( + SymbolLine[0 3500 0 4500 800] + SymbolLine[0 3500 500 3000 800] + SymbolLine[500 3000 1500 3000 800] + SymbolLine[1500 3000 2000 3500 800] + SymbolLine[2000 3500 2000 4500 800] + SymbolLine[1500 5000 2000 4500 800] + SymbolLine[500 5000 1500 5000 800] + SymbolLine[0 4500 500 5000 800] +) +Symbol['p' 1200] +( + SymbolLine[500 3500 500 6500 800] + SymbolLine[0 3000 500 3500 800] + SymbolLine[500 3500 1000 3000 800] + SymbolLine[1000 3000 2000 3000 800] + SymbolLine[2000 3000 2500 3500 800] + SymbolLine[2500 3500 2500 4500 800] + SymbolLine[2000 5000 2500 4500 800] + SymbolLine[1000 5000 2000 5000 800] + SymbolLine[500 4500 1000 5000 800] +) +Symbol['q' 1200] +( + SymbolLine[2000 3500 2000 6500 800] + SymbolLine[1500 3000 2000 3500 800] + SymbolLine[500 3000 1500 3000 800] + SymbolLine[0 3500 500 3000 800] + SymbolLine[0 3500 0 4500 800] + SymbolLine[0 4500 500 5000 800] + SymbolLine[500 5000 1500 5000 800] + SymbolLine[1500 5000 2000 4500 800] +) +Symbol['r' 1200] +( + SymbolLine[500 3500 500 5000 800] + SymbolLine[500 3500 1000 3000 800] + SymbolLine[1000 3000 2000 3000 800] + SymbolLine[0 3000 500 3500 800] +) +Symbol['s' 1200] +( + SymbolLine[500 5000 2000 5000 800] + SymbolLine[2000 5000 2500 4500 800] + SymbolLine[2000 4000 2500 4500 800] + SymbolLine[500 4000 2000 4000 800] + SymbolLine[0 3500 500 4000 800] + SymbolLine[0 3500 500 3000 800] + SymbolLine[500 3000 2000 3000 800] + SymbolLine[2000 3000 2500 3500 800] + SymbolLine[0 4500 500 5000 800] +) +Symbol['t' 1000] +( + SymbolLine[500 1000 500 4500 800] + SymbolLine[500 4500 1000 5000 800] + SymbolLine[0 2500 1000 2500 800] +) +Symbol['u' 1200] +( + SymbolLine[0 3000 0 4500 800] + SymbolLine[0 4500 500 5000 800] + SymbolLine[500 5000 1500 5000 800] + SymbolLine[1500 5000 2000 4500 800] + SymbolLine[2000 3000 2000 4500 800] +) +Symbol['v' 1200] +( + SymbolLine[0 3000 1000 5000 800] + SymbolLine[2000 3000 1000 5000 800] +) +Symbol['w' 1200] +( + SymbolLine[0 3000 0 4500 800] + SymbolLine[0 4500 500 5000 800] + SymbolLine[500 5000 1000 5000 800] + SymbolLine[1000 5000 1500 4500 800] + SymbolLine[1500 3000 1500 4500 800] + SymbolLine[1500 4500 2000 5000 800] + SymbolLine[2000 5000 2500 5000 800] + SymbolLine[2500 5000 3000 4500 800] + SymbolLine[3000 3000 3000 4500 800] +) +Symbol['x' 1200] +( + SymbolLine[0 3000 2000 5000 800] + SymbolLine[0 5000 2000 3000 800] +) +Symbol['y' 1200] +( + SymbolLine[0 3000 0 4500 800] + SymbolLine[0 4500 500 5000 800] + SymbolLine[2000 3000 2000 6000 800] + SymbolLine[1500 6500 2000 6000 800] + SymbolLine[500 6500 1500 6500 800] + SymbolLine[0 6000 500 6500 800] + SymbolLine[500 5000 1500 5000 800] + SymbolLine[1500 5000 2000 4500 800] +) +Symbol['z' 1200] +( + SymbolLine[0 3000 2000 3000 800] + SymbolLine[0 5000 2000 3000 800] + SymbolLine[0 5000 2000 5000 800] +) +Symbol['{' 1200] +( + SymbolLine[500 1500 1000 1000 800] + SymbolLine[500 1500 500 2500 800] + SymbolLine[0 3000 500 2500 800] + SymbolLine[0 3000 500 3500 800] + SymbolLine[500 3500 500 4500 800] + SymbolLine[500 4500 1000 5000 800] +) +Symbol['|' 1200] +( + SymbolLine[0 1000 0 5000 800] +) +Symbol['}' 1200] +( + SymbolLine[0 1000 500 1500 800] + SymbolLine[500 1500 500 2500 800] + SymbolLine[500 2500 1000 3000 800] + SymbolLine[500 3500 1000 3000 800] + SymbolLine[500 3500 500 4500 800] + SymbolLine[0 5000 500 4500 800] +) +Symbol['~' 1200] +( + SymbolLine[0 3500 500 3000 800] + SymbolLine[500 3000 1000 3000 800] + SymbolLine[1000 3000 1500 3500 800] + SymbolLine[1500 3500 2000 3500 800] + SymbolLine[2000 3500 2500 3000 800] +) +Attribute("PCB::grid::unit" "mil") + +Element["" "Dual in-line package, medium wide (400 mil)" "" "DIP14M" 62500 22500 22000 5000 3 100 ""] +( + Pin[0 0 6000 3000 6600 2800 "1" "1" "square"] + Pin[0 10000 6000 3000 6600 2800 "2" "2" ""] + Pin[0 20000 6000 3000 6600 2800 "3" "3" "thermal(1S)"] + Pin[0 30000 6000 3000 6600 2800 "4" "4" "square,shape(3)"] + Pin[0 40000 6000 3000 6600 2800 "5" "5" "square,shape(2)"] + Pin[0 50000 6000 3000 6600 2800 "6" "6" "square,shape(4)"] + Pin[0 60000 6000 3000 6600 2800 "7" "7" "square,shape(8)"] + Pin[40000 60000 6000 3000 6600 2800 "8" "8" "square,shape(8)"] + Pin[40000 50000 6000 3000 6600 2800 "9" "9" "square,shape(4)"] + Pin[40000 40000 6000 3000 6600 2800 "10" "10" "square,shape(2)"] + Pin[40000 30000 6000 3000 6600 2800 "11" "11" "square,shape(3)"] + Pin[40000 20000 6000 3000 6600 2800 "12" "12" ""] + Pin[40000 10000 6000 3000 6600 2800 "13" "13" ""] + Pin[40000 0 6000 3000 6600 2800 "14" "14" "square,shape(1)"] + ElementLine [-5000 -5000 -5000 65000 1000] + ElementLine [-5000 65000 45000 65000 1000] + ElementLine [45000 65000 45000 -5000 1000] + ElementLine [-5000 -5000 15000 -5000 1000] + ElementLine [25000 -5000 45000 -5000 1000] + ElementArc [20000 -5000 5000 5000 0 180 1000] + + ) +Layer(1 "component") +( +) +Layer(2 "solder") +( + Line[10000 17500 67500 17500 1500 5000 "clearline"] + Line[67500 17500 77500 27500 1500 5000 "clearline"] + Line[77500 27500 85000 27500 1500 5000 "clearline"] + Line[62500 22500 37500 22500 1500 5000 "clearline"] + Line[10000 27500 67500 27500 1500 5000 "clearline"] + Line[67500 27500 77500 37500 1500 5000 "clearline"] + Line[77500 37500 85000 37500 1500 5000 "clearline"] + Line[62500 32500 45000 32500 1500 5000 "clearline"] + Line[10000 37500 67500 37500 1500 5000 "clearline"] + Line[67500 37500 77500 47500 1500 5000 "clearline"] + Line[77500 47500 85000 47500 1500 5000 "clearline"] + Line[62500 42500 27500 42500 1500 5000 ""] + Line[10000 47500 67500 47500 1500 5000 "clearline"] + Line[67500 47500 77500 57500 1500 5000 "clearline"] + Line[77500 57500 85000 57500 1500 5000 "clearline"] + Line[62500 52500 37500 52500 1500 5000 "clearline"] + Line[37500 57500 67500 57500 1500 5000 "clearline"] + Line[67500 57500 77500 67500 1500 5000 "clearline"] + Line[77500 67500 85000 67500 1500 5000 "clearline"] + Line[62500 62500 37500 62500 1500 5000 "clearline"] + Line[37500 67500 67500 67500 1500 5000 "clearline"] + Line[67500 67500 77500 77500 1500 5000 "clearline"] + Line[77500 77500 85000 77500 1500 5000 "clearline"] + Line[62500 72500 37500 72500 1500 5000 "clearline"] + Line[37500 77500 67500 77500 1500 5000 "clearline"] + Line[67500 77500 77500 87500 1500 5000 "clearline"] + Line[77500 87500 85000 87500 1500 5000 "clearline"] + Line[62500 82500 37500 82500 1500 5000 "clearline"] + Line[65000 32500 60000 32500 6000 5000 "clearline"] + Line[105000 32500 100000 32500 6000 5000 "clearline"] + Line[102500 32500 125000 32500 1500 5000 "clearline"] + Line[102500 52500 125000 52500 1500 5000 "clearline"] + Line[102500 62500 125000 62500 1500 5000 "clearline"] + Line[102500 72500 125000 72500 1500 5000 "clearline"] + Line[102500 82500 125000 82500 1500 5000 "clearline"] + Line[102500 22500 125000 22500 1500 5000 "clearline"] + Polygon("clearpoly") + ( + [55000 37500] [70000 37500] [70000 47500] [55000 47500] + ) + Polygon("clearpoly") + ( + [85000 7500] [117500 7500] [117500 92500] [85000 92500] + ) +) +Layer(3 "GND") +( +) +Layer(4 "power") +( +) +Layer(5 "signal1") +( +) +Layer(6 "signal2") +( +) +Layer(7 "signal3") +( +) +Layer(8 "signal4") +( +) +Layer(9 "silk") +( +) +Layer(10 "silk") +( + Text[10000 17500 0 130 "square" "clearline"] + Text[10000 27500 0 130 "fat trace" "clearline"] + Text[10000 37500 0 130 "poly" "clearline"] + Text[25000 95000 1 130 "with [square]" "clearline"] + Text[15000 92500 1 130 "shaped pins" "clearline"] +) Index: trunk/doc-rnd/features/square.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc-rnd/features/square.png =================================================================== --- trunk/doc-rnd/features/square.png (nonexistent) +++ trunk/doc-rnd/features/square.png (revision 2495) Property changes on: trunk/doc-rnd/features/square.png ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: trunk/doc-rnd/features/tostyle.html =================================================================== --- trunk/doc-rnd/features/tostyle.html (nonexistent) +++ trunk/doc-rnd/features/tostyle.html (revision 2495) @@ -0,0 +1,50 @@ + + +

pcb-rnd - the [tostyle] patch

+ +Footprints bring their own hole sizes, copper ring sizes and clearances. +These parameters often depend on the manufacturing process, and such a value +coming from a footprint may differ much from the values used on the board already. +

+PCB has actions (and menus and hotkeys) to change sizes manually. In my practice, +I try to stick to the sizes defined in my routing styles and try to avoid +manually changing clearances or ring sizes. Still, the random values coming +from various footprints should be changed. +

+After many years of struggling with this, I realized the feature I need is +a way to change object sizes to not a relative or absolute number but +to the current routing style. The [tostyle] patch does exactly this. +It implements the following new features: +

change clearance size now works on elements: it changes the clearance of all pins/pads; this is the same as change drill has been working for a long time +
size change actions normally take a value and a unit; if the value is not a number but text style, the value is copied from the currently active routing style +
a new ChangeSizes() action that attempts to execute the other three change size actions with the same arguments and fails only if all of them failed; the three sizes are: main size, drill size, clearance size +
a menu item and hotkey binding to key 'Shift+Y' (for routing stYle) that calls ChangeSizes() of the selected or current object(s) to resize them to the current routing style +

+The new route style set works on: +

lines and arcs: sets their line width and clearance +
vias and individual pins: sets their ring dia, drill dia and clearance +
individual pads: sets their clearance +
elements: set all their pins and pads +

+ +

Example

+GUI: select a routing style; hover above a line, a via, a pin/pad of an element +or the silk of an element; press Shift+Y; undo if necessary. +

+CLI: select objects, execute action ChangeSizes(selected, style) +

+CLI: to adjust drill sizes only: select objects, execute action ChangeDrillSize(selected, style) + + +

save/load and compatibility

+Not affected, since the patch introduces actions and UI changes, no change +related to the data model. + +

plans

+No plans, the feature is complete. + + + Index: trunk/doc-rnd/features/unglib.html =================================================================== --- trunk/doc-rnd/features/unglib.html (nonexistent) +++ trunk/doc-rnd/features/unglib.html (revision 2495) @@ -0,0 +1,17 @@ + + +

pcb-rnd - the [unglib] patch

+ +Removes glib dependency from core, in favor of +minilibs to help +keeping the code small, modular +and easier to fix. + +

save/load and compatibility

+Not affected. + +

plans

+Remove glib dependency from the puller plugin. + + + Index: trunk/doc-rnd/index.html =================================================================== --- trunk/doc-rnd/index.html (revision 2494) +++ trunk/doc-rnd/index.html (revision 2495) @@ -23,33 +23,33 @@ Change summary, per topic:

commit message tag and doc	description -
[gpmi]	scripting PCB (including GUI dialogs, actions, menus, changing the layout) -
[intconn]	component internal connections -
[nonetlist]	components that are not part of the netlist and should not cause shorts -
[tostyle]	actions, menu and hotkey to change ring dia, line width, drill dia and clearance sizes to match the values defined for the current routing style -
[mincut]	minimal cut based warnings on shorts -
[square]	change square pad to a generic shaped-pin based on the octagon pin code - this is an alternative to teardrops -
[flagcomp]	unknown flag compatibility -
[scconfig]	use scconfig instead of autotools -
[pcb-fp]	generic parametric footprints; on-the-fly footprint generation by external tools written in any language (remove m4 hardwirings) -
[pcblib], [fp_fs], - [pcblib-param]	clean up the footprint library shipped -
[library_t]	footprint library is an arbitrary tree instead of a special, 2 level tree -
[fp_wget]	web based footprint libraries, integration of gedasymbols.org -
[res]	replace resource files with lihata and enable multi-key hotkeys in both gtk and lesstif hids -
[debian]	Debian packaging the binaries configured to my own taste -
[ba]	back annotation -
[onpoint]	on-point by Robert Drehmel -
[cycdrag]	cycle drag; with additional feature: negative box select +
[gpmi]	scripting PCB (including GUI dialogs, actions, menus, changing the layout) +
[intconn]	component internal connections +
[nonetlist]	components that are not part of the netlist and should not cause shorts +
[tostyle]	actions, menu and hotkey to change ring dia, line width, drill dia and clearance sizes to match the values defined for the current routing style +
[mincut]	minimal cut based warnings on shorts +
[square]	change square pad to a generic shaped-pin based on the octagon pin code - this is an alternative to teardrops +
[flagcomp]	unknown flag compatibility +
[scconfig]	use scconfig instead of autotools +
[pcb-fp]	generic parametric footprints; on-the-fly footprint generation by external tools written in any language (remove m4 hardwirings) +
[pcblib], [fp_fs], + [pcblib-param]	clean up the footprint library shipped +
[library_t]	footprint library is an arbitrary tree instead of a special, 2 level tree +
[fp_wget]	web based footprint libraries, integration of gedasymbols.org +
[res]	replace resource files with lihata and enable multi-key hotkeys in both gtk and lesstif hids +
[debian]	Debian packaging the binaries configured to my own taste +
[ba]	back annotation +
[onpoint]	on-point by Robert Drehmel +
[cycdrag]	cycle drag; with additional feature: negative box select
[mods]	modularize the code to reduce core size - for comparison, previous stats: 1.0.8, 1.0.9 -
[unglib]	remove glib dependency from core -
[io_*]	.pcb and .fp file format plugins -
[dynstyle]	dynamic routuing style: sypport more than 4 of them - with no limit -
[conf]	new, unified, config file system -
settings	minor changes in default settings +
[unglib]	remove glib dependency from core +
[io_*]	.pcb and .fp file format plugins +
[dynstyle]	dynamic routuing style: sypport more than 4 of them - with no limit +
[conf]	new, unified, config file system +
settings	minor changes in default settings - +

I have plans on my TODO list - these have lower priority compared to the features above. Index: trunk/doc-rnd/motivation.html =================================================================== --- trunk/doc-rnd/motivation.html (revision 2494) +++ trunk/doc-rnd/motivation.html (revision 2495) @@ -46,8 +46,8 @@

Most probably I won't merge anything back from the mainstream to my fork - the past few years showed that it's unlikely there would be new features I'd need

My plans for new features were:

pin shapes (a preliminary version is already implemented) -
1206 jumpers without having to add them on the schematics/netlist (done: [intconn] and [nonetlist] are the PCB-side features for this) +
pin shapes (a preliminary version is already implemented) +
1206 jumpers without having to add them on the schematics/netlist (done: [intconn] and [nonetlist] are the PCB-side features for this)
merge pcb-gpmi; GPMI would be an optional addon, it'd probably stay a plugin, but there should not be a separate repo ( done )

@@ -62,11 +62,11 @@ As I got more familiar with the code base, I decided to bite the bullet and do some refactoring:

replaced the footprint mapping/loading code; instead of a hardwired m4 dependency, parametric (generated-on-the-fly) footprints can be written in any language -
replaced the default footprint library shipped with the software; the new library ships a small, well organized collection of essentials, omitting special/rarely used footprints +
replaced the footprint mapping/loading code; instead of a hardwired m4 dependency, parametric (generated-on-the-fly) footprints can be written in any language +
replaced the default footprint library shipped with the software; the new library ships a small, well organized collection of essentials, omitting special/rarely used footprints
got the code much more modular - a lot of core code got converted into plugins -
threw out the resource parser and file format (manu.res and friends) in favor of lihata; this removed a lot of code duplication and a strangely designed resource tree data structure I really hated; as a side effect the gtk hid has multi-stroke hotkeys -
replaced glib with a set of mini libs in core and most of the plugins; at the end only the gtk hid should depend on glib; this made the code easier to maintain and debug; a lot of checks are now compile-time (through the C type system) instead of runtime (glib lists) +
threw out the resource parser and file format (manu.res and friends) in favor of lihata; this removed a lot of code duplication and a strangely designed resource tree data structure I really hated; as a side effect the gtk hid has multi-stroke hotkeys +
replaced glib with a set of mini libs in core and most of the plugins; at the end only the gtk hid should depend on glib; this made the code easier to maintain and debug; a lot of checks are now compile-time (through the C type system) instead of runtime (glib lists)
replaced the settings/rc/preferences system with a central, lihata based configuration system - long term hid attributes will be converted too