kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 07/05/2014 07:26 AM, Lorenzo Marcantonio wrote:
> Looking around the new code... is there a reason for not having
> assembly/courtyard in the non_cu array in PCBIO_format?

Those two layers could be added to non_cu[]

> also why having
> that array in the first place and simply using the enabled layers in the
> board object... 

Tho board file format policy decision was kept local to the board saving code here.  This
array establishes the order in the board level (layers) element, and I wanted it local to
the code doing the saving.

The set ANDing is done in 598 with SetEnabledLayers().Seq(..)

This is once per board, so its a very low cost (performance-wise) tuning knob on on the
order in the *.kicad_pcb file, for this one element only.

Those non-technical names however are not actually needed in the board level (layers)
element, since they may not be renamed currently.  And I dis-favour ever supporting
renaming the current ones, because it will detract from the human being taught how to read
the pretty format over time.  I want to establish familiarity with pretty, this means
non-English speaker need to learn the terse technical names.


So we have agreement only on the notion that we could add the two technical footprint
layers there.


> it doesn't seem an order is meaningful in the layer
> descriptor at the beginning of the file to me.
>