Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » KiCAD
  • » [Kicad-developers] New part file format units discussion. [RSS Feed]

#1 Dec. 15, 2010 20:07:51

Wayne S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] New part file format units discussion.


Dick and I have been discussing his ideas on making schematics and therefore
parts dimensionless. The more I think about it, the more I like it. Please
look over the discussion below and feel free to comment. I have also attached
the revised part specification with Brian's part renaming suggestion.

Wayne

-------- Original Message --------
Subject: Re: Patch for kicad gal
Date: Wed, 15 Dec 2010 13:07:23 -0600
From: Dick Hollenbeck <d***@*oftplc.com>
To: Wayne Stambaugh <wstamba***@*ilon.com>

On 12/15/2010 12:23 PM, Wayne Stambaugh wrote:
> On 12/15/2010 12:15 PM, Dick Hollenbeck wrote:
>> On 12/15/2010 10:55 AM, Dick Hollenbeck wrote:
>>> On 12/15/2010 10:18 AM, Wayne Stambaugh wrote:
>>>> On 12/14/2010 5:44 PM, Dick Hollenbeck wrote:
>>>>> On 12/14/2010 03:38 PM, Wayne Stambaugh wrote:
>>>>>> On 12/14/2010 1:54 PM, Dick Hollenbeck wrote:

<<< snipped >>>

>>>>>>>
>>>>>>> As I was reading your spec. I began to wonder if it would be helpful
>>>>>>> for *human
>>>>>>> writability* if:
>>>>>>>
>>>>>>> The units of the coordinate system were grid oriented. In other words,
>>>>>>> if we could
>>>>>>> superimpose an additional cartesian coordinate system that was at a
>>>>>>> lesser resolution
>>>>>>> onto the normal coordinate system.
>>>>>>>
>>>>>>> In this mode, pins might be 1 unit apart, vertically or horizontally.
>>>>>>>
>>>>>>> Don't know if we can do the same for text or pin names. But maybe.
>>>>>>> Maybe this makes
>>>>>>> writing Sweet with a text editor easier?
>>>>>>>
>>>>>>>
>>>>>>> (gxy X Y) grid coordinate (maybe it implies a division of X and Y by
>>>>>>> 50 or so.)
>>>>>>>
>>>>>>> (xy X Y) units coordinate
>>>>>> I'm not 100% sure if I follow you. If the xy coordinates where in terms
>>>>>> of
>>>>>> grid (gxy), wouldn't that mean a conversion in order to figure out where
>>>>>> a item
>>>>>> is located relative to the grid?
>>>>> Again, I am not over selling, but I want you to understand my original
>>>>> thinking, at
>>>>> least enough to tell me it's foolish or not worth it:
>>>>>
>>>>> First I start by assuming dimensions in the schematic are not even
>>>>> important unless I
>>>>> go to print. Dimensions, i.e. *scaling*, could be added at the eleventh
>>>>> hour just
>>>>> before printing. EESCHEMA only.
>>>>>
>>>>>
>>>>> What is important is that the grid let me connect wires to pins. So if
>>>>> the pins are
>>>>> on grid points, the wires are on grid points, then what is not on a grid
>>>>> point? Text
>>>>> can be on a grid point. What is left is arcs, curves, but very little
>>>>> else.
>>>>>
>>>>> Therefore, in some cases all we need is a ficticious coordinate system
>>>>> that is based
>>>>> entirely on grid points *alone*.
>>>>>
>>>>> If (xy 100 200) were a valid point before, then (gxy 1 2) becomes the
>>>>> *same* exact
>>>>> point expressed in grid coordinates, assuming the grid was 100 x 100
>>>>> original units.
>>>>>
>>>>> Basically what this does is eliminate some trailing zeros, on the
>>>>> assumption that grid
>>>>> points are the only points of interest, and that the grid is a multiple
>>>>> of 10. If the
>>>>> grid is 200 x 200:
>>>>>
>>>>> then (xy 200 2000) becomes (gxy 1 20)
>>>>>
>>>>> And the author of the code in his TEXT EDITOR might find this easier.
>>>>>
>>>>> It requires that you don't ever need to go off grid. And admittedly
>>>>> this is not the
>>>>> case with curves. So I don't know if it is easier or harder.
>>>>>
>>>>> That is one line of thought, two coordinate systems.
>>>>>
>>>>> An alternative line of thought is to have one coordinate system but have
>>>>> it BE the
>>>>> grid system in all cases, and use fractions to go off grid, like (xy 1.25
>>>>> 4.5). So
>>>>> pins *by request or by definition* are one X unit or one Y unit apart.
>>>>> Then only at
>>>>> time of printing do you assign the scaling factor, and which point you
>>>>> can stretch the
>>>>> schematic to any size you want. Likewise during editing, you can stretch
>>>>> to any size
>>>>> you want. The schematic is essentially dimension-less.
>>>> This concept has a lot going for it. I like the idea of a dimension-less
>>>> schematics. You would never have to worry about pins being off grid and
>>>> not
>>>> connecting properly to a wire or bus no matter where you placed them in the
>>>> schematic. My main concern is how easy is this going to be for users to
>>>> understand given that the initial part file editor is going be text based.
>>>> Converting off grid part coordinates is going to be confusing. It will
>>>> also
>>>> make specifying things like line width and text height and width relative
>>>> to
>>>> the grid spacing difficult as well. A graphical editor may be required to
>>>> draw
>>>> off grid elements properly. This will definitely have to be determined
>>>> before
>>>> we start coding.
>>> Well we can make all the new kids wear uniforms to school, metaphorically.
>>> This means
>>> we challenge the need for text that does not fit within a grid unit. Maybe
>>> all text
>>> is the same size in EESCHEMA, by default any way.
>>>
>>>
>>> Converting existing symbols over we can simply use fractional numbers if
>>> they go off
>>> grid. But
>>>
>>>
>>> (pin ..(xy 1 2) ..)
>>> (pin ..(xy 2 2) ..)
>>>
>>> gets pretty easy, it reminds me of using graph paper as a kid. In fact a
>>> person could
>>> draw his part on graph paper and then simply key it into a text editor.
>>>
>>>
>>>
>>> Line width, two alternatives:
>>>
>>> A) Line width can be imposed globally on a schematic for screen drawing or
>>> printing,
>>> each separately controllable globally. But all lines would be same width.
>>>
>>>
>>> B) Line width takes on the units of "percent of a grid cell", so a width of
>>> 100 would
>>> be one cell wide (fat line), 200 would be 2 cells wide (fatter line), and
>>> 1 would be
>>> 1 percent of a grid cell, or a single pixel if greater. 5 would be about
>>> right I think.
>>>
>>>
>>>
>>> Where there is a will, there is a way.
>>>
>>> If we can achieve human *writability* this will mean major things to the
>>> adoption of
>>> Sweet. BTW, I had never contemplated not writing a graphical editor also,
>>> but now it
>>> is at least a remote possibility, could actually be omittable if we can get
>>> this easy
>>> enough.
>>>
>>> (I had envisioned *both* textual and graphical, with the graphical elements
>>> the of
>>> base parts being off limits to graphical editing unless the inheritance was
>>> meant to
>>> be a full blown copying.)
>>>
>>> The last thing to remember about this dimensionless concept, is that you
>>> would never
>>> have a schematic that would not fit on the page. It would always fit, it
>>> just might
>>> be harder to read, since it would be small. Or if you are lucky, you get
>>> to make it
>>> really big as you go blind and old.
>> Text:
>>
>> The anchor point for text would be on grid too, so you would have enough
>> space below
>> capital letters so that the text could reside above a wire or pin without
>> stepping on it.
>>
>> Sort of like the PCBNEW wire label concept.
>>
>> That whitespace offset beneath the font, would be hard coded into our stuff,
>> so the
>> user never has to think too much about it. Text and wires co-mingle nicely.
>> Text is
>> on grid from a Sweet standpoint.
>>
>> That way pin names and explicit separate text would be on the same level.
>>
>> Well I've almost talked myself into this now. If you are nearly sold, we
>> may want to
>> ask for more opinions, feel free to do that if so.
> I'm sold. I'll remove the GAL stuff and forward this email conversation to
> the
> mailing list for comments if there are no objections.
>
> Wayne

No objections.

For line width you can add a 3rd alternative, that being to use the same
dimensionless
units as everything else. So instead of a line width of 5 for 5% of a grid,
you would
simply say .05

And you can get a lot of mileage by publishing defaults, or by using global
settings,
so only line specific overrides have to be expressed in Sweet. Therefore line
width
may not even be needed most of the time. When parsing, you could set the
binary line
width value to -1, and let either the default pertain, or a global.

Same for text size, could be in grid/snap units too. A height of 1 means
just less
than a full grid cell. Height of .5 means half high. Or you could go with the
cell
*percent* on both, probably means less decimal points, but who cares either way.


Dickeeschema_part_sexpr_format_EN.odtDescription:application/vnd.oasis.opendocument.text_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Attachments:
attachment eeschema_part_sexpr_format_EN.odt (26.0 KB)

Offline

#2 Dec. 16, 2010 01:16:49

Brian S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] New part file format units discussion.


On 15 December 2010 20:07, Wayne Stambaugh <wstamba***@*ilon.com> wrote:
> Dick and I have been discussing his ideas on making schematics and therefore
> parts dimensionless.  The more I think about it, the more I like it.  Please
> look over the discussion below and feel free to comment.  I have also attached
> the revised part specification with Brian's part renaming suggestion.
>
> Wayne
>
> -------- Original Message --------
> Subject: Re: Patch for kicad gal
> Date: Wed, 15 Dec 2010 13:07:23 -0600
> From: Dick Hollenbeck <d***@*oftplc.com>
> To: Wayne Stambaugh <wstamba***@*ilon.com>
>
> On 12/15/2010 12:23 PM, Wayne Stambaugh wrote:
>> On 12/15/2010 12:15 PM, Dick Hollenbeck wrote:
>>> On 12/15/2010 10:55 AM, Dick Hollenbeck wrote:
>>>> On 12/15/2010 10:18 AM, Wayne Stambaugh wrote:
>>>>> On 12/14/2010 5:44 PM, Dick Hollenbeck wrote:
>>>>>> On 12/14/2010 03:38 PM, Wayne Stambaugh wrote:
>>>>>>> On 12/14/2010 1:54 PM, Dick Hollenbeck wrote:
>
> <<< snipped >>>
>
>>>>>>>>
>>>>>>>> As I was reading your spec.  I began to wonder if it would be helpful
>>>>>>>> for *human
>>>>>>>> writability* if:
>>>>>>>>
>>>>>>>> The units of the coordinate system were grid oriented.  In other
>>>>>>>> words, if we could
>>>>>>>> superimpose an additional cartesian coordinate system that was at a
>>>>>>>> lesser resolution
>>>>>>>> onto the normal coordinate system.
>>>>>>>>
>>>>>>>> In this mode, pins might be 1 unit apart, vertically or horizontally.
>>>>>>>>
>>>>>>>> Don't know if we can do the same for text or pin names.  But maybe.  
>>>>>>>> Maybe this makes
>>>>>>>> writing Sweet with a text editor easier?
>>>>>>>>
>>>>>>>>
>>>>>>>> (gxy X Y)   grid coordinate  (maybe it implies a division of X and Y
>>>>>>>> by 50 or so.)
>>>>>>>>
>>>>>>>> (xy X Y)    units coordinate
>>>>>>> I'm not 100% sure if I follow you.  If the xy coordinates where in
>>>>>>> terms of
>>>>>>> grid (gxy), wouldn't that mean a conversion in order to figure out
>>>>>>> where a item
>>>>>>> is located relative to the grid?
>>>>>> Again, I am not over selling, but I want you to understand my original
>>>>>> thinking, at
>>>>>> least enough to tell me it's foolish or not worth it:
>>>>>>
>>>>>> First I start by assuming dimensions in the schematic are not even
>>>>>> important unless I
>>>>>> go to print.  Dimensions, i.e. *scaling*, could be added at the eleventh
>>>>>> hour just
>>>>>> before printing.  EESCHEMA only.
>>>>>>
>>>>>>
>>>>>> What is important is that the grid let me connect wires to pins.  So if
>>>>>> the pins are
>>>>>> on grid points, the wires are on grid points, then what is not on a grid
>>>>>> point?  Text
>>>>>> can be on a grid point.  What is left is arcs, curves, but very little
>>>>>> else.
>>>>>>
>>>>>> Therefore, in some cases all we need is a ficticious coordinate system
>>>>>> that is based
>>>>>> entirely on grid points *alone*.
>>>>>>
>>>>>> If (xy 100 200) were a valid point before, then (gxy 1 2) becomes the
>>>>>> *same* exact
>>>>>> point expressed in grid coordinates, assuming the grid was 100 x 100
>>>>>> original units.
>>>>>>
>>>>>> Basically what this does is eliminate some trailing zeros, on the
>>>>>> assumption that grid
>>>>>> points are the only points of interest, and that the grid is a multiple
>>>>>> of 10.  If the
>>>>>> grid is 200 x 200:
>>>>>>
>>>>>> then (xy 200 2000)  becomes (gxy 1 20)
>>>>>>
>>>>>> And the author of the code in his TEXT EDITOR might find this easier.
>>>>>>
>>>>>> It requires that you don't ever need to go off grid.   And admittedly
>>>>>> this is not the
>>>>>> case with curves.  So I don't know if it is easier or harder.
>>>>>>
>>>>>> That is one line of thought, two coordinate systems.
>>>>>>
>>>>>> An alternative line of thought is to have one coordinate system but have
>>>>>> it BE the
>>>>>> grid system in all cases, and use fractions to go off grid, like (xy
>>>>>> 1.25 4.5).  So
>>>>>> pins *by request or by definition* are one X unit or one Y unit apart.  
>>>>>> Then only at
>>>>>> time of printing do you assign the scaling factor, and which point you
>>>>>> can stretch the
>>>>>> schematic to any size you want.  Likewise during editing, you can
>>>>>> stretch to any size
>>>>>> you want.  The schematic is essentially dimension-less.
>>>>> This concept has a lot going for it.  I like the idea of a dimension-less
>>>>> schematics.  You would never have to worry about pins being off grid and
>>>>> not
>>>>> connecting properly to a wire or bus no matter where you placed them in
>>>>> the
>>>>> schematic.  My main concern is how easy is this going to be for users to
>>>>> understand given that the initial part file editor is going be text based.
>>>>> Converting off grid part coordinates is going to be confusing.  It will
>>>>> also
>>>>> make specifying things like line width and text height and width relative
>>>>> to
>>>>> the grid spacing difficult as well.  A graphical editor may be required
>>>>> to draw
>>>>> off grid elements properly.  This will definitely have to be determined
>>>>> before
>>>>> we start coding.
>>>> Well we can make all the new kids wear uniforms to school, metaphorically.
>>>>  This means
>>>> we challenge the need for text that does not fit within a grid unit.  
>>>> Maybe all text
>>>> is the same size in EESCHEMA, by default any way.
>>>>
>>>>
>>>> Converting existing symbols over we can simply use fractional numbers if
>>>> they go off
>>>> grid.  But
>>>>
>>>>
>>>> (pin ..(xy 1 2) ..)
>>>> (pin ..(xy 2 2) ..)
>>>>
>>>> gets pretty easy, it reminds me of using graph paper as a kid.  In fact a
>>>> person could
>>>> draw his part on graph paper and then simply key it into a text editor.
>>>>
>>>>
>>>>
>>>> Line width, two alternatives:
>>>>
>>>> A) Line width can be imposed globally on a schematic for screen drawing or
>>>> printing,
>>>> each separately controllable globally.  But all lines would be same width.
>>>>
>>>>
>>>> B) Line width takes on the units of "percent of a grid cell", so a width
>>>> of 100 would
>>>> be one cell wide (fat line), 200 would be 2 cells wide (fatter line),  and
>>>> 1 would be
>>>> 1 percent of a grid cell, or a single pixel if greater.  5 would be about
>>>> right I think.
>>>>
>>>>
>>>>
>>>> Where there is a will, there is a way.
>>>>
>>>> If we can achieve human *writability* this will mean major things to the
>>>> adoption of
>>>> Sweet.  BTW, I had never contemplated not writing a graphical editor also,
>>>> but now it
>>>> is at least a remote possibility, could actually be omittable if we can
>>>> get this easy
>>>> enough.
>>>>
>>>> (I had envisioned *both* textual and graphical, with the graphical
>>>> elements the of
>>>> base parts being off limits to graphical editing unless the inheritance
>>>> was meant to
>>>> be a full blown copying.)
>>>>
>>>> The last thing to remember about this dimensionless concept, is that you
>>>> would never
>>>> have a schematic that would not fit on the page.  It would always fit, it
>>>> just might
>>>> be harder to read, since it would be small.  Or if you are lucky, you get
>>>> to make it
>>>> really big as you go blind and old.
>>> Text:
>>>
>>> The anchor point for text would be on grid too, so you would have enough
>>> space below
>>> capital letters so that the text could reside above a wire or pin without
>>> stepping on it.
>>>
>>> Sort of like the PCBNEW wire label concept.
>>>
>>> That whitespace offset beneath the font, would be hard coded into our
>>> stuff, so the
>>> user never has to think too much about it.  Text and wires co-mingle
>>> nicely.  Text is
>>> on grid from a Sweet standpoint.
>>>
>>> That way pin names and explicit separate text would be on the same level.
>>>
>>> Well I've almost talked myself into this now.  If you are nearly sold, we
>>> may want to
>>> ask for more opinions, feel free to do that if so.
>> I'm sold.  I'll remove the GAL stuff and forward this email conversation to
>> the
>> mailing list for comments if there are no objections.
>>
>> Wayne
>
> No objections.
>
> For line width you can add a 3rd alternative, that being to use the same
> dimensionless
> units as everything else.  So instead of a line width of 5 for 5% of a grid,
> you would
> simply say .05
>
> And you can get a lot of mileage by publishing defaults, or by using global
> settings,
> so only line specific overrides have to be expressed in Sweet.  Therefore line
> width
> may not even be needed most of the time.  When parsing, you could set the
> binary line
> width value to -1, and let either the default pertain, or a global.
>
> Same for text size, could be in grid/snap units too.    A height of 1 means
> just less
> than a full grid cell.  Height of .5 means half high.  Or you could go with
> the
> cell
> *percent* on both, probably means less decimal points, but who cares either
> way.
>
>
> Dick

I actually think this solves a problem I nearly always have with ECAD systems.

I want to create A4 schematics because that is what I always print
out, I never print larger than A4 and no-one else who uses the
schematics use a paper source larger than A4 (probably letter over in
the states). But, most systems have their components drawn to target
A3 or even A2 schematic pages, so you can never create a true A4
schematic with the library parts because you can only ever fit a
couple of components on the page. Then I'm forced to draft on a larger
sheet, but this then means that all of the dimensions I type in which
are in mm or in. become totally meaningless because everything's
scaled wrong.

Dimensioned units are basically meaningless in a schematic symbol to
me, so the move to dimensionless units gets a thumbs up from me. I'm
sure it has more advantages than I can list here...

Best Regards,

Brian.

_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#3 Dec. 16, 2010 09:19:38

Martijn K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] New part file format units discussion.


On Dec 16, 2010, at 1:16 AM, Brian Sidebotham wrote:

> On 15 December 2010 20:07, Wayne Stambaugh <wstamba***@*ilon.com> wrote:
>> Dick and I have been discussing his ideas on making schematics and therefore
>> parts dimensionless. The more I think about it, the more I like it. Please
>> look over the discussion below and feel free to comment. I have also
>> attached
>> the revised part specification with Brian's part renaming suggestion.
>>
>> Wayne
>>
>> -------- Original Message --------
>> Subject: Re: Patch for kicad gal
>> Date: Wed, 15 Dec 2010 13:07:23 -0600
>> From: Dick Hollenbeck <d***@*oftplc.com>
>> To: Wayne Stambaugh <wstamba***@*ilon.com>
>>
>> On 12/15/2010 12:23 PM, Wayne Stambaugh wrote:
>>> On 12/15/2010 12:15 PM, Dick Hollenbeck wrote:
>>>> On 12/15/2010 10:55 AM, Dick Hollenbeck wrote:
>>>>> On 12/15/2010 10:18 AM, Wayne Stambaugh wrote:
>>>>>> On 12/14/2010 5:44 PM, Dick Hollenbeck wrote:
>>>>>>> On 12/14/2010 03:38 PM, Wayne Stambaugh wrote:
>>>>>>>> On 12/14/2010 1:54 PM, Dick Hollenbeck wrote:
>>
>> <<< snipped >>>
>>
>>>>>>>>>
>>>>>>>>> As I was reading your spec. I began to wonder if it would be helpful
>>>>>>>>> for *human
>>>>>>>>> writability* if:
>>>>>>>>>
>>>>>>>>> The units of the coordinate system were grid oriented. In other
>>>>>>>>> words, if we could
>>>>>>>>> superimpose an additional cartesian coordinate system that was at a
>>>>>>>>> lesser resolution
>>>>>>>>> onto the normal coordinate system.
>>>>>>>>>
>>>>>>>>> In this mode, pins might be 1 unit apart, vertically or horizontally.
>>>>>>>>>
>>>>>>>>> Don't know if we can do the same for text or pin names. But maybe.
>>>>>>>>> Maybe this makes
>>>>>>>>> writing Sweet with a text editor easier?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> (gxy X Y) grid coordinate (maybe it implies a division of X and Y
>>>>>>>>> by 50 or so.)
>>>>>>>>>
>>>>>>>>> (xy X Y) units coordinate
>>>>>>>> I'm not 100% sure if I follow you. If the xy coordinates where in
>>>>>>>> terms of
>>>>>>>> grid (gxy), wouldn't that mean a conversion in order to figure out
>>>>>>>> where a item
>>>>>>>> is located relative to the grid?
>>>>>>> Again, I am not over selling, but I want you to understand my original
>>>>>>> thinking, at
>>>>>>> least enough to tell me it's foolish or not worth it:
>>>>>>>
>>>>>>> First I start by assuming dimensions in the schematic are not even
>>>>>>> important unless I
>>>>>>> go to print. Dimensions, i.e. *scaling*, could be added at the
>>>>>>> eleventh hour just
>>>>>>> before printing. EESCHEMA only.
>>>>>>>
>>>>>>>
>>>>>>> What is important is that the grid let me connect wires to pins. So if
>>>>>>> the pins are
>>>>>>> on grid points, the wires are on grid points, then what is not on a
>>>>>>> grid point? Text
>>>>>>> can be on a grid point. What is left is arcs, curves, but very little
>>>>>>> else.
>>>>>>>
>>>>>>> Therefore, in some cases all we need is a ficticious coordinate system
>>>>>>> that is based
>>>>>>> entirely on grid points *alone*.
>>>>>>>
>>>>>>> If (xy 100 200) were a valid point before, then (gxy 1 2) becomes the
>>>>>>> *same* exact
>>>>>>> point expressed in grid coordinates, assuming the grid was 100 x 100
>>>>>>> original units.
>>>>>>>
>>>>>>> Basically what this does is eliminate some trailing zeros, on the
>>>>>>> assumption that grid
>>>>>>> points are the only points of interest, and that the grid is a multiple
>>>>>>> of 10. If the
>>>>>>> grid is 200 x 200:
>>>>>>>
>>>>>>> then (xy 200 2000) becomes (gxy 1 20)
>>>>>>>
>>>>>>> And the author of the code in his TEXT EDITOR might find this easier.
>>>>>>>
>>>>>>> It requires that you don't ever need to go off grid. And admittedly
>>>>>>> this is not the
>>>>>>> case with curves. So I don't know if it is easier or harder.
>>>>>>>
>>>>>>> That is one line of thought, two coordinate systems.
>>>>>>>
>>>>>>> An alternative line of thought is to have one coordinate system but
>>>>>>> have it BE the
>>>>>>> grid system in all cases, and use fractions to go off grid, like (xy
>>>>>>> 1.25 4.5). So
>>>>>>> pins *by request or by definition* are one X unit or one Y unit apart.
>>>>>>> Then only at
>>>>>>> time of printing do you assign the scaling factor, and which point you
>>>>>>> can stretch the
>>>>>>> schematic to any size you want. Likewise during editing, you can
>>>>>>> stretch to any size
>>>>>>> you want. The schematic is essentially dimension-less.
>>>>>> This concept has a lot going for it. I like the idea of a dimension-less
>>>>>> schematics. You would never have to worry about pins being off grid and
>>>>>> not
>>>>>> connecting properly to a wire or bus no matter where you placed them in
>>>>>> the
>>>>>> schematic. My main concern is how easy is this going to be for users to
>>>>>> understand given that the initial part file editor is going be text
>>>>>> based.
>>>>>> Converting off grid part coordinates is going to be confusing. It will
>>>>>> also
>>>>>> make specifying things like line width and text height and width
>>>>>> relative to
>>>>>> the grid spacing difficult as well. A graphical editor may be required
>>>>>> to draw
>>>>>> off grid elements properly. This will definitely have to be determined
>>>>>> before
>>>>>> we start coding.
>>>>> Well we can make all the new kids wear uniforms to school,
>>>>> metaphorically. This means
>>>>> we challenge the need for text that does not fit within a grid unit.
>>>>> Maybe all text
>>>>> is the same size in EESCHEMA, by default any way.
>>>>>
>>>>>
>>>>> Converting existing symbols over we can simply use fractional numbers if
>>>>> they go off
>>>>> grid. But
>>>>>
>>>>>
>>>>> (pin ..(xy 1 2) ..)
>>>>> (pin ..(xy 2 2) ..)
>>>>>
>>>>> gets pretty easy, it reminds me of using graph paper as a kid. In fact a
>>>>> person could
>>>>> draw his part on graph paper and then simply key it into a text editor.
>>>>>
>>>>>
>>>>>
>>>>> Line width, two alternatives:
>>>>>
>>>>> A) Line width can be imposed globally on a schematic for screen drawing
>>>>> or printing,
>>>>> each separately controllable globally. But all lines would be same width.
>>>>>
>>>>>
>>>>> B) Line width takes on the units of "percent of a grid cell", so a width
>>>>> of 100 would
>>>>> be one cell wide (fat line), 200 would be 2 cells wide (fatter line),
>>>>> and 1 would be
>>>>> 1 percent of a grid cell, or a single pixel if greater. 5 would be about
>>>>> right I think.
>>>>>
>>>>>
>>>>>
>>>>> Where there is a will, there is a way.
>>>>>
>>>>> If we can achieve human *writability* this will mean major things to the
>>>>> adoption of
>>>>> Sweet. BTW, I had never contemplated not writing a graphical editor
>>>>> also, but now it
>>>>> is at least a remote possibility, could actually be omittable if we can
>>>>> get this easy
>>>>> enough.
>>>>>
>>>>> (I had envisioned *both* textual and graphical, with the graphical
>>>>> elements the of
>>>>> base parts being off limits to graphical editing unless the inheritance
>>>>> was meant to
>>>>> be a full blown copying.)
>>>>>
>>>>> The last thing to remember about this dimensionless concept, is that you
>>>>> would never
>>>>> have a schematic that would not fit on the page. It would always fit, it
>>>>> just might
>>>>> be harder to read, since it would be small. Or if you are lucky, you get
>>>>> to make it
>>>>> really big as you go blind and old.
>>>> Text:
>>>>
>>>> The anchor point for text would be on grid too, so you would have enough
>>>> space below
>>>> capital letters so that the text could reside above a wire or pin without
>>>> stepping on it.
>>>>
>>>> Sort of like the PCBNEW wire label concept.
>>>>
>>>> That whitespace offset beneath the font, would be hard coded into our
>>>> stuff, so the
>>>> user never has to think too much about it. Text and wires co-mingle
>>>> nicely. Text is
>>>> on grid from a Sweet standpoint.
>>>>
>>>> That way pin names and explicit separate text would be on the same level.
>>>>
>>>> Well I've almost talked myself into this now. If you are nearly sold, we
>>>> may want to
>>>> ask for more opinions, feel free to do that if so.
>>> I'm sold. I'll remove the GAL stuff and forward this email conversation to
>>> the
>>> mailing list for comments if there are no objections.
>>>
>>> Wayne
>>
>> No objections.
>>
>> For line width you can add a 3rd alternative, that being to use the same
>> dimensionless
>> units as everything else. So instead of a line width of 5 for 5% of a grid,
>> you would
>> simply say .05
>>
>> And you can get a lot of mileage by publishing defaults, or by using global
>> settings,
>> so only line specific overrides have to be expressed in Sweet. Therefore
>> line
>> width
>> may not even be needed most of the time. When parsing, you could set the
>> binary line
>> width value to -1, and let either the default pertain, or a global.
>>
>> Same for text size, could be in grid/snap units too. A height of 1 means
>> just less
>> than a full grid cell. Height of .5 means half high. Or you could go with
>> the
>> cell
>> *percent* on both, probably means less decimal points, but who cares either
>> way.
>>
>>
>> Dick
>
> I actually think this solves a problem I nearly always have with ECAD systems.
>
> I want to create A4 schematics because that is what I always print
> out, I never print larger than A4 and no-one else who uses the
> schematics use a paper source larger than A4 (probably letter over in
> the states). But, most systems have their components drawn to target
> A3 or even A2 schematic pages, so you can never create a true A4
> schematic with the library parts because you can only ever fit a
> couple of components on the page. Then I'm forced to draft on a larger
> sheet, but this then means that all of the dimensions I type in which
> are in mm or in. become totally meaningless because everything's
> scaled wrong.
>
> Dimensioned units are basically meaningless in a schematic symbol to
> me, so the move to dimensionless units gets a thumbs up from me. I'm
> sure it has more advantages than I can list here...
>
> Best Regards,
>
> Brian.


I agree totally with Brian (who agrees with Wayne and Dick) :-)
I imagine a print-function where you select a rectangle around the parts you
want to print (kind-a of zoom in). So I get all components on A4 (or whatever)
and can print sections (power supply section, IO-section, etc.) easily on
separate sheets in a readable size, without having to do complex multi-sheet
schematics.
Of course, this wish-function does not mean it has to be implemented in
library, is is just an example of the use of it.

Dimensionless schematics, cool! We can probably add some defaults to
text-sizes, such as component_name_size, pin_name, pin_number, etc. and make
them dependent of each other: component_name_size = 2 * pin_name, pin_name =
0.05 (* grid), etc. This way we can scale all text-fields by just changing one
of them.

/Martijn




_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

  • Root
  • » KiCAD
  • » [Kicad-developers] New part file format units discussion. [RSS Feed]

Board footer

Moderator control

Enjoy the 21st of August
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support