kicad-developers team mailing list archive
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
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
> 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,
> 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
> This is a from the SWEET spec, don't know what your concern is, even after reading it 5-6
>> 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
>> - 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