Home manufacturing by printing a PCB on paper is not a good way to verify features at this scale.
How can you know that the output of your printer is the same as the input of your printer? I would not be surprised that part of the “Resolution enhancement” of your printer is adjusting the edges between black / white subtlety.
If you have a laser printer and your picture is transfered 1:1 to the static rolls in the printer, then there is still an analog process of wheter the toner sticks to the roll or not on the edges, and printers try to correct for such things, which is guesswork in the printer firmware.
The whole explanation about drilled hole size versus finised plated hole size is also not relevant in this context.
You are talking about “printed copper” features of the hole, while in real PCB manufacture the holes are usually drilled first before the copper is etched. The holes in the PCB appear nowhere in the Gerber files. There are no hole features in the copper. They simply do not exist in the Gerber file.
Hole size is only specified by the drill sizes in the excellon drill file. And as said before, manufacturers usually do some guesswork and use larger drills (which are also stronger) in an attempt to manufacture a finished hole in the size of what is specified in the drill file.
For home manufacturing it is also not usefull to have holes in the THT pads of the size of the finished drill. The best for hand drilling is a slight dimple in the center of the hole, just big enough to use as a guide to keep the drill centered.
If we assume an angle on the point of the drill of 120 degrees and a copper tickness of 35um then the etched hole in the copper should have a size of roughly
2sqrt(3) 35um, which is 121.24um.
If you etch a bigger hole into the copper before drilling, then the point of the drill touches the epoxy before the cutting edge of the point touches the copper, and the hole in the copper is not used as a guide anymore to center your drill.
In the hobby market there has been some software that takes a gerber file, and an excellon drill file and punches small drill starter holes in the pads. If you find (or write) such a program, the locations of your drilled holes will be more accurate.
On the other hand, If printer output for via hole size is different from pdf output, then it looks like a bug, and if reported properly it will very likely get fixed (according to some unspecified triage process). This is a user forum, and though some of the developers may also roam here, it is not the proper way to file bug reports.
Also remember that a lot of the development of KiCad is done by volunteers in their spare time.
The proper way to file a bug report is on Launchpad, and before you file a bug report there, you should first check if the same bug has already been mentioned by someone else. If it’s already mentioned, you can add the info you have, or file a new bug if it’s new.
Also, this implies you have a lot more knowledge about this bug:
Bravo for looking into the code and analysing it!
Things like that take time and effort.
But if you’ve found the location of this rounding error, you know in which file and in which line number it is. If you have analysed the rounding error, you probably have also thought of a better solution.
If you file a bug report, then a short explanation of why it is a rounding error, and how it can be corrected are usefull additions, and should be mentioned in the bug report (Along of course with a complete copy of your KiCad version from the “About” box).
A developer willing to put some time into fixing this buy may not have looked at that particular piece of code ever. That piece of code may have been unchanged for years.
Adding the info mentioned above will very much improve the likelyhood that it gets fixed fast, even if it is a very small and low priority bug.
A few months ago I made a bug report of a small error with an offset of pads in one of the footprint wizards, and it got fixed within a few days after reporting. The bug I’m writing about here was:
https://bugs.launchpad.net/kicad/+bug/1825261
Phew, a lot of typing for such a small thing.