kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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.

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!

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?

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