The reference on fab is for the fabrication drawings.
It’s size is restricted by the scale you chose for printing these drawings.
(The KLC specifies 1mm for both the reference on fab and silk.)
I personally also use the fab reference during the layout phase. (I disable silk)
The fab layer contains the components outline. (the real size. The silk layer is by definition outside the component.)
And it contains a reference.
The crucial difference in my personal libraries is that the reference on fab is a lot smaller. (depending on the part 0.5mm to 1mm)
My personal libraries also have all fab references inside the component.
By the way a lot of the footprints are generated with a python script.
Using this it is very easy to generate your personal libraries to your liking.
If you are willing to create your own libraries you could do what i do.
I have the %R user text on the silk layer and the main reference on the fab layer.
This way i can change the visibility of all references on the fab layer in the render tab. (And still have them there if i want a more complete documentation.)
Why is an unofficial draft spec being used for new commits to the official libraries? There are so many changes, it should be numbered 2.0, not a minor revision. The scripts refer to rule numbers, which have now all changed.
This is crazy. The library management is completely out of control. I really feel sorry for new users, because it is such a mess. I shall recommend to new users to avoid official libraries completely.
Feel free to help out.
I agree with you that the new specs should be accessible for everyone.
(maybe give a link in the old version stating that the next version is under way and that it will look similar to the linked version. Regarding the version number: do be honest i don’t really care what the KLC is called.)
Why is version 1.2 used instead of the current version (1.1). I think this is because the version 1.1 does not make sense in some parts. (refdes only on fab layer, size of refdes 2mm, …)
By the way the changes came about because of this:
I think that is half the problem, too many cooks spoil the broth. Different people come in and make random changes depending on their own whim.
The first thing to do is create a stable release branch which has strict change control (the KiCad code is a good example here). Then a dev branch where non-compatible changes can be made.
Currently we have the worst of both worlds, breaking changes being made to the master branch, and hundreds of PRs held back because they don’t conform to the latest KLC, even though because the KLC keeps changing 99% of the existing parts don’t conform to the latest KLC anyway.
It doesn’t help that due to a half-written github plugin, the libraries are spread over dozens of different repositories, the names of which are also randomly changing. There is no way to put a version number into parts, or indicate what spec they conform to, or who and when the part was checked, all of which a proper system would have.
I don’t know if any of the maintainers have worked with a formal engineering change process, but the libraries desperately need to adopt one before the libraries descend into complete chaos.