← Back to team overview

kicad-developers team mailing list archive

Re: I read the new eeschema file format


On 5/17/2012 5:33 AM, Lorenzo Marcantonio wrote:
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


Please make a copy of this email and save it until I'm ready to address it. Otherwise, I'll forget most of it. The reason I sent the new schematic file format document to you directly was to avoid opening up this discussion. Apparently I did not make that clear in the email that I sent to you. For everyone who has there fingers over their keyboards to ask for a copy of the spec or comment on this, please hold off until I have time to be part of the discussion and keep track of everything. Thank you for your patience.