kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Sat, Jul 05, 2014 at 09:20:11AM -0500, Dick Hollenbeck wrote:
> 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.

I wasn't referring about renaming issues... in fact if we consider
'deprecated' the layer number (except for determining the copper order)
the layer tag is the only thing identifying the layer meaning;
I have absolutely no problem with that; I've already exposed my doubts
about that naming irregularity but there was a design decision for that,
so that's OK.

The question is why putting in the (layers ...) element the other
unrenameable layers like margin, paste, silk and so on but not these
four?

AFAIK the purpose of the layers element is:

- Enumerating the used layers: not strictly necessary since the set is
  fixed in the code; but tells how many copper layers are in use;

- Mapping layer number with names: only necessary for copper layers
  since they can be renamed; the internal number for the other one is an
  internal detail (in fact, it changed with the new set :D);

- Declaring layer type: yet again only useful for copper layers (IIRC is
  only used by the SPECCTRA exporter, however it's a needed info);

- Telling layer visibility: that would be useful for *every* layer; ATM
  you can't say "courtyard top is hidden" and I think that's an
  insertion anomaly (in DB-speak); the schema would support that, it's
  only missing the relationship row:P

- (proposed) adding other user information relevant to the layer (like
  a comment, user name or whatever)

So at the end they should be in the table at least for saving the
visibility status; on the other hand (if visibility status and other
info are decided to be not-so-important) every layer which is not copper
could be elided from the table without loss.

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

Yes, I was simply asking if there was a design issue or simply they were
forgotten from the list array (like for the interpretation of the
"*.CrtYd" keyword).

In short, the core question was: "why silk is there but not fabrication
and assembly?"; nothing else

As for the ordering array itself I see no useful purpose in keeping it
around for that element but I don't care either... it's just yet another
table that needs to be kept in sync, have fun with it:D

-- 
Lorenzo Marcantonio
Logos Srl