kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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