← Back to team overview

kicad-developers team mailing list archive

Re: I read the new eeschema file format



Thanks for taking the time to review the document.  Please disregard my previous reply to
your comments.

You have read the document, and unfortunately I have not.

I realize there is a difference between concept and expression of the concept. 

There is no reason for me to defend a concept until we know we have the expression of the
concept correct.


> On 05/17/2012 04: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).
> All our s-expression files are utf8, with lowercase ASCII keywords.
> I don't think it can be said any clearer than that.  ASCII is a valid 8 bit encoding also,
> and fits nicely into UTF8 as a subset.
> I think you can learn more by reading Documentation/s-expressions.txt
>>  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? 
> This is a from the SWEET spec, don't know what your concern is, even after reading it 5-6
> times.
>> 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.
> What?  Nothing in the above paragraph makes sense, it only makes my brain hurt.
> You may be over thinking it.  We don't need to assume anything about decimal points in our
> files.
>> - 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'?