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'?
