kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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
>