X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Fri, 5 Sep 2014 22:43:12 +0200 From: Bernd Walter To: geda-user AT delorie DOT com Subject: Re: [geda-user] Chinese glyph rendering in pcb as symbols Message-ID: <20140905204312.GJ3196@cicely7.cicely.de> References: <201409051618 DOT s85GIdb8024685 AT envy DOT delorie DOT com> <5409F1C2 DOT 3090406 AT xs4all DOT nl> <201409051752 DOT s85Hqnr2027362 AT envy DOT delorie DOT com> <20140905184829 DOT GH3196 AT cicely7 DOT cicely DOT de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1,BAYES_00=-1.9,T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Fri, Sep 05, 2014 at 03:11:04PM -0400, Jason White wrote: > On Fri, Sep 5, 2014 at 2:48 PM, Bernd Walter wrote: > >> I think zip would certainly be the most flexible path, that way you > >> can keep the human readable layout files and include whatever fonts or > >> images are required without inserting huge ASCII-encoded binary blobs > >> all over the place. > >> > >> The tools and scripts would still work, all you'd have to do is feed them > >> the text file from the zip. > > > > I consider this impractical if you regulary switch between text editor > > and PCB. > > And it completely breaks revision control systems without having a > > specific ZIP plugin. > > I'm curious if that is a very common use case among gEDA users? No idea. But the file format is very well documented and much easier to get than some of the UI features. Counting number of elements? Start PCB, export the bom, then count, or just: [485]devel> grep '^Element' pcb | wc -l 560 This is also quite handy without the wc to get an overview about the Element flags used - sometimes some unintended sneaked it. Same for Via, Pins, Pads, ... Sometimes the count is required to get an idea about manufactoring costs. > I certainly spend a lot more time in the tool than the text editor. Depend on which point in design I am. I also spend most time in PCB for doing the layout itself. However there are some points I prefer doing outside. In many cases I don't knwo how to do it in PCB, or if it's possible at all. Some examples: Switch DRC setting for another board manufactorer, or optional higher density feature set. Just copy the DRC line is easy compared to go through all values by hand. I do this a lot, as well as checking drawing properties. Sometimes you switch if DRC clearance There are a few I ocassionally change inside PCB, such as polygone clearance or unique devicenames (for panelizing). I do some automatic checks on wether those are in my default state. I do all my footprint designs in text editor with PCB running at the same time to visually inspect result (recent PCB versions detect newer file dates and ask for reload). The reason to do so is using exact locations and sizes is much easier in the ASCII format than on screen, even became easier since PCB started accepting mm values. You can see if there are any changes at all before check in a new version. Sounds simple, but in fact it has some strange dependencies. For some time the crosshair position was saved, therefor it alwazs had changes, then it started randomly reordering components. There are many other things I do, such as mass updating flags and so on. Now (20140316) it randomly switches some values from mm to mil and back: [484]devel> svn diff Index: pcb =================================================================== --- pcb (revision 6621) +++ pcb (working copy) @@ -5845,7 +5845,7 @@ ) -Element["" "AT91SAM7S321" "Q1" "LQFP64_10" 206.8805mm 37.7820mm 20.00mil 60.00mil 2 100 ""] +Element["" "AT91SAM7S321" "Q1" "LQFP64_10" 8144.90mil 37.7820mm 20.00mil 60.00mil 2 100 ""] ( Pad[207.36mil 3.7498mm 241.34mil 3.7498mm 11.02mil 30.00mil 14.02mil "1" "1" "square,edge2"] Pad[207.36mil 127.95mil 241.34mil 127.95mil 11.02mil 30.00mil 14.02mil "2" "2" "square,edge2"] @@ -7185,7 +7185,7 @@ ) -Element["" "AT91SAM7S321" "Q1" "LQFP64_10" 206.8805mm 89.2170mm 20.00mil 60.00mil 2 100 ""] +Element["" "AT91SAM7S321" "Q1" "LQFP64_10" 8144.90mil 89.2170mm 20.00mil 60.00mil 2 100 ""] ( Pad[207.36mil 3.7498mm 241.34mil 3.7498mm 11.02mil 30.00mil 14.02mil "1" "1" "square,edge2"] Pad[207.36mil 127.95mil 241.34mil 127.95mil 11.02mil 30.00mil 14.02mil "2" "2" "square,edge2"] > I somewhat curious about your work flow. Do/can you branch and merge > PCB designs like source code? Are you using some external scripts to > generate features in your boards? I do branches, but merging almost always has to be done manually. Very often i start project by reusing an existing layout, because a new project just differs in some peripheral area. Some of the unrequired part is wiped out by editor, some by PCB. Sometimes the diffs help to distribute changes in common parts, but it still is a lot of work. The switch from pure mil values to mil values made it harder, but I consider this a one time switch. One of the most uncommon branch I do is for pogo pin adapters. I branch the PCB file, remove all vias and wiring. Then I add pseudo vias where I want pogo pins, where I have tooling holes, at which positions the board has bare surface and can be pushed down on the pogo needles, ... Then I save, remove temporarily all components and export the drill file, which is for the "vias" only, since I removed the components. This is all done in PCB, but whenever my design changes I can easily update the Elements in the pogo branch and handle the changes. This can be done within PCB as well, but if done outside I can see what changes there are and if I (for whatever reason) I missed something. And I don't have to grab the mouse for that. > What about treating directories as files like the Netbeans IDE does > with its projects? Then optionally compressing them into a zip. > That would make it play nice with just about any version control > program while still allowing portable designs. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.