On 11/20/2013 6:23 PM, Dick Hollenbeck wrote: > On 11/20/2013 12:48 PM, Wayne Stambaugh wrote: >> On 11/19/2013 5:23 PM, Edwin van den Oetelaar wrote: >>> Testing library view in CvPCb. >>> Latest bzr. >>> >>> EuroBoard_Outline >>> View Selected Footprint window active. >>> I have the 3D viewer open. (error does not happen when 3D is closed) >>> >>> Select: >>> EuroBoard_Outline:EuroBoard160mmX100mm or >>> EuroBoard_Outline:EuroBoard160mmX100mm_holes >>> >>> happens also with >>> PFF_PSF_PSS_Leadforms:PFF_Leadform_5pins >>> >>> >>> Get error message : >>> ----- >>> IO_ERROR: Unable to find the next segment with an endpoint of (0 mm, >>> -99.9998 mm). >>> Edit Edge.Cuts perimeter graphics, making them contiguous polygons each. >>> from /home/oetelaar/kicad_sources/kicad.bzr/pcbnew/specctra.cpp : >>> ThrowIOError() : line 120 >>> >>> Unable to calculate the board outlines. >>> Therefore use the board boundary box. >> >> I confirmed this. All of these footprints are defined with an unclosed >> PCB edge cut area. That explains the 3D error about contiguous >> polygons. There is also PCB_LINE_T assertion in debug builds because >> technically footprints are not allowed to have PCB edge cut layers. At >> some point, this will probably be fixed so that any PCB edge cuts will >> be merged with the board edge cuts to create the final board outline. >> As of right now, you are taking your chances by defining footprints with >> PCB edge cuts. >> >> >>> ----- >>> >>> More serious (I think, something with the embedded slash char) >>> Select: SMD packages >>> Select: SMDHD/VF >>> >>> Get error message: >>> ----- >>> IO_ERROR: lib table contains no logical lib 'VF' >>> from /home/oetelaar/kicad_sources/kicad.bzr/common/fp_lib_table.cpp : >>> FindRow() : line 592 >> >> Using path separators in module names was not an issue in the legacy >> file format. With the pretty format, it will cause the file path to be >> incorrect. I have it on my todo list to add filtering to prevent new >> modules names from containing illegal file name and path characters. I >> will have to add this test when converting other library formats to the >> pretty format. My guess is this is what happened in this case. For >> now, we will have the fix them by hand as we come across them. >> Hopefully there wont be too many of them. > > > We ran into that in the EAGPLE_PLUGIN. The simplest solution was to simply > lie about the > name encountered when loading the footprint. > > This is done in function > > static bool fix_eagle_package_name( string* aName ) > > in the eagle plugin. But it now looks like the strategy could have general > applicability, > including in LEGACY_PLUGIN.
It might be a good idea to make this public for use in other plugins when attempting to save pretty libraries. > > The advertised names are converted before even using them, from > FootprintLoad() or cacheLib(). > > This is the chosen path for EAGLE anyways. > > Note that it was not good enough to do a character to character swap. That > lead to a > duplicate footprint name. No foolin', murphy is always in charge. > > > We were swapping '/' with say '-'. > > > But then ran into a library with say both 'XYZ/' and 'XYZ-' in the same > library! Nobody ever said this was going to be easy :) > > Back to the drawing board. What's now in place is a URL encoding like > substitution. > Nobody would ever name their footprint 'XYZ%2f' would they? It seems like it would be safe but I wouldn't bet on it. There is always that one person who will confound your logic. Wayne > > Please say no, because finding a unique name is the goal. After one read / > write cycle, a > person can always use the module editor to rename anything with a % in it. > Or in the case > of pretty, just a file manager. > > > Dick > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
