kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

My comments:
- Nitpicking: please decide, or UTF-8 or ASCII :D on a technicality
  ASCII is a *character set* (codepoints 0 to 127, single byte direct
  encoding), UTF-8 is an *encoding* (for the full Unicode repertoire,
  usually). So the correct phrasing should be 'Files must be composed
  by Unicode characters encoded in UTF-8' or at least 'File must be in
  UTF-8 encoded text'.

- Page 2 type: co4ordinates :P
  
- Very interesting the pins on an integer grid idea. But wouldn't this
  leave us open to the 'floating point coordinates' issue we avoided in
  pcbnew? I think we could keep all to ints using a grid like that used
  in Type1 fonts: pins on multiples of (say 1000 or 1024) and other
  stuff in between (but integer anyway). In other words, fixed point
  with implicit decimal position.

- Do the 'schematic element may be embedded' means there will be no more
  separate .sch files for each sheet? If so, good. I think that's
  superceded by the 'circuit' element, right?

- I'm not to keen on the 'footprint clearance and layer restriction' in
  the eeschema file... what are they for? If we add them the next
  logical addition would be forcing positions and so on (like for fixing
  holes and stuff), that's a thing of pcbnew competence. Netclass
  assignment is indeed a good idea (since it's a "class", not an
  explicit 'wide that, clearance that' declaration)

- Why differentiate between line and polyline? these are actually the
  same thing

- Good idea with the line style. It's somewhat inconvenient to have note
  lines always dashed and component lines always continuous. Drawing
  isolation barriers in components is a PITA:P

- Also: consider migrating graphical elements (lines, arcs, bezier,
  circles) to a path based system (like postscript, PDF or cairo); the
  reason: at the moment filling primitive isn't very useful because the
  whole boundary is stroked and the fill is not always what it should
  be.  Consider how it's impossible to represent not a traditional OR
  gate.  Path based object are relatively easy to represent and draw,
  *but* UI would be a little more complicated for creation and editing
  (well, there is no shape editing now, anyway). I think that with the
  (postscript) primitives moveto, lineto, arcto e curveto we should be
  able to represent anything (heck, PDF does it without arcto!). curveto
  would be probably still generated only by the bitmap converter anyway.

- Radiuses (and dimensions in general) should be *always* in user units.
  Otherwise putting the 'mils' in the equation you'll needlessly
  complicate scaling... or is there a reason to have everything scalable
  *except* radiuses?

- The use of color in text doesn't appeal to me... either you put the
  option on each primitive or remove it from text (IMHO is more useful
  enforce 'logical' colors than allow rainbow commenting). Use case:
  I usually use black background and I open a schematic with colors
  'optimized' for a white background: horrible things would happen.
  Instead of RGB you could add a specification for a 'logical' color
  (but I don't see a reason...)

- Also the 'effect' expression is redundant... they could simple be
  accepted directly under the text/properties element. For example
  the 'at' element is right inside the text element while for properties
  (both schematic and component) is in an effect element. Instead of the
  effect element a 'style' table could be usefully defined (think about
  CSS classes) containing essentially the font definition (not position
  or alignment). So you could resize/reshape attributes at a global
  level instead of picking each single attribute in the editor.

- better explain the type encoding for bus entries: a bus entry can be
  wire to wire or wire to bus *and* in two different orientations; maybe
  it's better to have two fields).

- Wire and buses should have 'start' and 'end' elements instead of
  'xy'... unless you want to save strips like polylines (but I don't see
  any advantage)

- Please explain the 'schematic elements go here if the sheet is not
  derived from another sheet'. In particular, what do you mean with
  'derive'?

-- 
Lorenzo Marcantonio
Logos Srl