I don’t know whether it is intentional or bug but Y coordinate values of components, texts or cursor seem to be inverted for me. As you can see from the screenshot, Y value is positive at the given cursor point. The origin is at the center of the component. X values are normal. Any ideas?
Library Part Editor, KiCad version 2016-04-23 BZR 6710
I think that’s intentional. All kicad tools (including pcb_new and footprint editor) use this coordinate system.
It makes drawing board outlines confusing until you get used to it
There are several things in KiCad that work the opposite way to expectation. A pin with “right” orientation points left, up pins are down. X key flips in Y, and Y flips in X. The left key in the 3D view scrolls the window to the right. There are some others I think.
Eventually you get used to it, but I’ve often wondered why the wierdness.
confusing it is.
why did someone feel the urge to invert one axis and not the other
puzzling
This quirk also makes translators and scripts from other packages more of a pain.
I doubt this can be fixed, as it is rather entrenched now.
I think way,way back around year 0 in computing, pixels were addressed with top-left as 0,0, which means X increased Right,and Y increased down. Meanwhile Maps and CAD drawings have always been first quadrant based, = X increases right, Y increases up.
Seems that pixel thinking was used in early KiCad.
I really wonder the intention here. When I look to the corresponding line at the corresponding .lib file, coordinates of texts (F0, F1, F2…) are represented in normal coordinate system, i.e. non-inverted Y-axis.
Time to time, I contributed kicad-library repository and checked new symbols with a python script called checklib.py. It reports coordinates in normal notation (non-inverted Y-axis). Inconsistency between that script and the KiCad itself confuses me.
I think it is more historical accident than clear intention.
They probably could fix the Part editor visual axis, as that is somewhat local, but the design canvas has to match the ASCII cordinates and legacy files so I don’t see a way to ‘fix’ that & be backward compatible.
Of course, fixing one area only, means design canvas and editor canvas, then differ…
Huh, I never noticed that. Cool.
The consequences of the various KiCad programs starting off as independent applications, written by different people.
Backwards compatibility stops any change now, so the best we can hope for is some accurate and clear documentation explaining the rules
Won’t the lib format be redone and replaced by something like .sweet?
Slightly OT, but historically graphic displays have always been rendered by hardware with (0,0) at top left. This precedes pixel graphics, it goes back to character generators (e.g. MC6845). Probably makes sense for character displays which are read top down.
I think it is coincidence that the CRT scanlines also proceed top down. If the refresh rate is high then is shouldn’t matter, although the very first TV systems used some very slow scan rates. But even the original mechanical TV with a scanning “Nipkow” disc had a hole pattern that scanned top down.
There is no particularly good reason that applications written in the past 30 years should not fix the axis, it saves a small calculation when drawing which is nearly insignificant. Every PC application I wrote since the start of Windows (3.1) I have always put the Y axis to match a “normal” XY layout. All modern window managers seem to allow custom transforms, so it is almost transparent to application code.
History aside… I tried to find the spec for the new library format but failed, I am sure Wayne posted a link to it on the dev list. Anyone have a link ?
Something here, but five! years old
Presumably this will be another directory plus file per symbol approach
Discussion is informative, thank you all!
That’s easy - KiCad is using a Screen Coordinate with the upper left at (0,0). Technical drawings such as in datasheets are in a 2D Cartesian coordinate. In the distant past using the screen coordinate system may have provided some small advantage when calculating coordinates for drawing and testing for a ‘hit’ but I have no idea what the historical reason is. At any rate we can bet that this won’t change because it would involve a huge change in the code (plotting, printing, 3D rendering and export, etc).
That depends on how you define “points”, as the pin doesn’t actually have any arrows on it. It could be considered to be “pointing” towards the symbol. I would agree however, that it would make it more intuitive if a “left” pin was placed on the left side of the symbol.
X mirrors about the ‘X’ axis, Y mirrors about the ‘Y’ axis, anything else would be weird.
No, it scrolls the object being viewed to the left. Not that uncommon, sometimes you can choose whether you scroll the viewport or the contents.
And that is still how it is today. Most raster scan graphics systems have the origin at the top left as this position corresponds to the first memory location in hardware. And the display hardware usually scans left to right, top to bottom regardless of whether it is a CRT, LCD or even a printer. Most modern day software maps a different coordinate system onto the hardware, some even let you choose the coordinate system. But you can’t always assume it’s the cartesian coordinate system.
I guess you must be the “everything should be backwards, normal = weird” person KiCad is designed for 
Well I’m sure that in geometry class you were never told to “flip in Y” but rather “mirror about X”. Flip in Y is ambiguous at best, where is the mirror line? KiCad definitely has that one right. The other two I wouldn’t argue either way, but I do think left/right and up/down pins would be more intuitive if they were reversed. But there are a lot of other things I would rather see fixed first.
Just wanted to add my 2 cents worth here. This is another inconsistency with Kicad, relative to numerous other mechanical (EG Autocad) and Electrical/Electronic (eg Protel 99 and Altium) CAD packages. The bearing on how pixels were/still are presented graphically onscreen to me has little relevence. X/Y coordinate signs are well established for all 4 quadrants (long before computers too…). Even when a CAD package is only working in the single quadrant, the signs are both positive. This discrepancy in Kicad in my humble opinion should be corrected to
A. be mathematically correct and
B. Eliminate confusion for people experienced in other CAD packages, who opt to try out and use Kicad.
Thank you.
