I suspect you will get a lot of resistance to this, so you should have a strong well-reasoned argument. The following two reasons are among the strongest reasons against making this change that I can think of.
This will break the usability of the official libraries (the ones provided by default). Not an issue if you never use them, but most people will not totally eschew the official libraries. Until (if?) the schematic editor is rewritten to include things like magnetic snap, using a grid in the schematic that mismatches with the grid used to draw the symbols is a recipe for wires that don’t connect to pins and thus won’t create the netlist that you expect. The official libs are drawn with the pins on a 0.1" (100mil) grid, see this section from the KiCad Libray Convention (the standards to which the ofiicial libraries are drawn to).
If you want to pack more schematic on a page, choose a larger schematic page, and then scale down to what ever paper size your printer handles when you print.
Good luck, but I really don’t see the developers putting effort into something that is almost guaranteed to add to the number of user errors demanding support.
Personally, I’d probably be an advocate of changing the measuring system in eeschema to defining 1 drawing unit as 0.1" and only offering grids that fit that grid. Get rid of calling measurement in eeschema by real-world dimensions (maybe make a note in the documentation that 1 drawing unit is 0.1" when printed to scale).
Does it then even matter that right now that unit is called mil? (In other words we already have what you suggest but instead of it being called KiCad unit it is called 100 mil)
This is due in large part to the fact that territorially I am in the Russian Federation, and here are the current standards. And I would like to use KiCAD.
But the second question, can be solved as I understand it. This is to realize the ability to rotate an object to a specified angle, in the Symbol Editor.
With the various monitor sizes, 1 (whatever unit) will end up being different sizes displayed on the monitor. In addition to the fact that the user can zoom to any level as well.
The only time an accurate measurement would be required is when printing. Which is kinda funny as my V5 Eeschema is set to in, but when printing the margins are in mm.
Sorry, I wasn’t clear. Calling 1 drawing unit (in the UI) what we currently call 0.1". If, for nothing else, would mean that all the existing symbols in the library don’t have to be scaled. It doesn’t matter what the behind-the scenes unit is.
The issue with using real world units in an application where the only reason is how it fits on a printed page boils down to 3 countries. Liberia, Myanmar, and of course us here in the little 'ole US of A. If imperial units are used we are happy but everyone else wonders why an archaic measuring system is being used. If metric units are used then we go on a war path (with all the culturally misappropriated war paint and head dresses from the original Americans) decrying the socialism of being forced to use a system we aren’t familiar with. When both measuring systems are provided (yet the provided symbols really only work with one) then people get frustrated when they can’t get wires to connect to symbols and then throw KiCad out as being unusable. (All because KiCad provides a way for it to become unusable.)
I don’t care if 1 drawing unit is essentially equivalent to 1mm. Except that I wouldn’t want to be responsible for making our (volunteer) librarians scale all the libraries, especially given the titan effort that they have provided (again as volunteers) getting the libraries to their current consistent state.
BTW, I tried to make it obvious with my language choice, but my characterization of Americans is intended to be a gross exaggeration for effect. I’m one of the few people who would want to change to the metric measuring system. Probably because I’ve worked in the scientific field.
Also… this thread is getting way off topic. Does a mod want to split this conversation off into its own thread?
Wow. Your library manager must be really obsessive compulsive to demand that sort of precision on something that is just a symbol. Almost as bad as a font or logo designer.
I don’t know if those sorts of precision drawing tools are available in KiCad. You might have to draw it first in actual 2-D drafting software and then either
Write a script (your language of choice) to convert and ASCII dxf file to eeschema mod file (which is also ASCII) to import into the library editor.
Take note of the cartesian coordinates of all the line end points in your drafting program of choice and enter them by hand (after doing coordinate conversions) in the library editor. In the library editor you would have to put a line down, it could be randomly placed, and then edit it. From there you can enter the absolute coordinates numerically for both end points of the line.
Honestly, I would just draw it “close enough” and hope the library manager doesn’t notice any discrepancies.
I’m sure it would be a popular request, probably as an extension of the existing import bitmap tool to include support for vector logos in addition to bitmaps. This tool already has export functionality to schematic symbols, pcb footprints, layout title block elements, and bonus postscript .ps files. Why remake the wheel if all you need to do is paint on sidewalls?
But, as @davidsrsb already said, this is a user forum. Except for a few lurking exceptions, we are all users helping other users. If you want to request features, it is best to do that with the launchpad bug tracker. See this FAQ item for details:
I assume you are asking about drawing the “arrow”. Simply edit the coordinates of the two endpoints. With a little trig you can be as precise as you want to be.
Yeah, what @1.21Gigawatts said. But also, if eyeballing it is close enough, the finest grid (1mil/0.0254mm) should be small enough unless you are printing that single part scaled up to fit a poster.
!
