← Back to team overview

kicad-developers team mailing list archive

Re: [RFC] Symbol library file format

 

Hi Kristoffer,

On 1/4/2019 10:24 AM, Kristoffer wrote:
> On 2019-01-04 15:03, Wayne Stambaugh wrote:
> 
>> I can somewhat see the utility in this but it really doesn't make a lot
>> of sense to me.  Lets assume for a second that it would be useful to
>> create a separate atomic part for every 0603 resistor part number
>> currently available.  Given that the 0603 footprint file is 1.7K, the
>> step 3D model is 39.6K, the wrl 3D model is 14.4K, and the fully defined
>> symbol file would be about 1.5K so that's a total of 57.2K per atomic
>> part number.  Now if you create a unique part number for every
>> resistance value, tolerance, temperature coefficient, manufacturer, etc.
>> that would be tens if not hundreds of thousands of unique part numbers.
>>   100K unique atomic part numbers would require 5.72G of storage just for
>> the 0603 resistors.  Add all of the other resistors footprints including
>> THT and your talking about several 100G.  Add all of the other passive
>> components like capacitors, inductors, etc and you are talking about
>> several terabytes of storage.  Maybe I'm missing something but even with
>> modern storage systems, this doesn't scale well.
> 
> I agree totally, But today basically we treat the symbol as the ultimate
> storage unit for these things, so if one were so inclined, it would mean
> a lot of symbols instead.
> 
> Basically I just want the symbol to be the graphics to eeschema, and a
> higher level part unit keeping the relation of eeschema-graphics,
> pcbnew-graphics, metadata and documents information.
> 
> I am not advocating the need to generate parts for every resistor out
> there. Just that maybe we should allow the possibility for me to instead
> of sending a pdf, a footprint, a symbol, a 3d file, store them in
> different specific places to match what is written in the symbol file.
> 
> Just allow a part to define all of these in one file, or with relative
> paths with regards to the part file, for easier transfer to partners or
> similar.
> 

I'm not opposed to this idea but that is outside the scope of symbol
library file format.  This would be a different file format and discussion.


Follow ups

References