I think I submitted the round ends and other end bugs a long time ago, but unfortunately it didn’t get fixed in 9.3 so I had to use tricks, or just ignored it and put a lot of solder on the pin/trace to increase it’s current capacity.
I honestly believe if you are coming across this bug you are using too small of rings for the size of the trace. That is to say the ring needs to have at least as much copper around it as the trace is wide. So for a 128mil trace you need a 2mm ring otherwise your trace capacity is greater than the ring capacity which would defeat the purpose of using large traces.
Here is your sketch with the rings set to 2mm on the middle example and you will see it opens just fine and doesn’t need any workarounds.
bug fritzing.fzz (1.7 KB)
I would also like to say using that size trace is rarely needed unless you are dealing with high currents.
Also I believe the round ends on the traces are there so where two traces meet each other and form a corner you get a round corner not a sharp noisy corner.
It helps, but I don’t think I have the room for a bigger via.
If you delete the trace, make a new trace, and then change it to 120mil - it makes trace 1 -, then that is what I’d want.
I think the way Fritzing connects the end of a trace to a ring is to connect the center of the circle used for the end of the trace to the center line of the ring not the center of the hole. If that is the case I would imagine it would be a trivial change to make in the code if one were to know where to look.
I will try and poke around a little to see if I can find it.
If you do not have room for a larger via then do you need that large of a trace? The copper area in the hole of a via can not be equal to a 128mil trace, can it?
It’s going to part legs so the hole is filled.
There is also a trace kickout at bendpoint problem, but you get around it by not coming out at 90º.
I may have actually solved this. 
After a few tries I managed to find where it calculates the trace length for each type of pad/ring connection point in the source code. They were subtracting half of the trace width from the length if it was connected to a ring. I simply removed this bit of math and now the rounded end starts in the center of the hole. With smaller traces it looks a little ugly in the renders and could cause an issue with home etching if you rely on the copper divot to center your drill.
This is how it opens now.
This is how the copper Gerber layer looks. You can see the path intersection the hole in the via.
This is how the copper Gerber layer looks with the drill holes over the copper.
2 Likes
@Old_Grey it looks to also fix your issue when placing a bend point really close to a connection point.
Wow.
I actually home etch, and to center the drill I go to the pain of putting a 0.004" via on each pad because the usual 0.038" allows the drill to wander. Any chance you could keep the subtraction, but make it half the drill hole.
That is a good way to calculate it … but not easily for me. Currently it does not pass the hole diameter to the function that clips the path lengths. I believe it is relatively easy to pass it that data but I do not understand object oriented programming very well so it is not automatic for me.
Yeah I thought that might be a bit hard, considering a simple 0.020" std reduction on each end would be suitable in 90% of cases.
I’m still studying things. I have found in the gerberexport how it deals with drill holes so now if I can figure out how to use that data in the trace clipping function we would be set.
Wow! 
Many thanks for extra-fast (and “magic” for me!!!) resolution of this problem! 
Is the src/items/clipablewire.cpp modification replicable on a current installation (it’s a script I can change on my pc), or I must wait for a new full build of Fritzing?
Love open source and his communities!
Unfortunately it has to be compiled and built so It is not a change you can make on your current running system. This does mean having to wait for the next release.
Well… ok… Thanks 
Ideas about deadline for next release?
Or I can try to patch https://github.com/fritzing/fritzing-app/archive/0.9.3b.tar.gz and compile… 
If you patch that exact copy of Fritzing and compile it you would be best off. As it stands development has stalled and there are a few of us trying to get it going again but that means it could be a long time before another release. Also the current development version has a lot of bugs so you must use the source you linked to not the Github repo.
If you are a linux user I could provide a working compiled copy of Fritzing with the patch. If you are a Windows or Mac user you will have to figure it out on your own because I do not have a system to compile it against. If you do end up compiling it on one of those systems I am sure everyone would be happy if you shared your success and your experience.
Hi Sublimeartistry,
I read above that you wanted the circuits to not go to the center of the pads (clipping). This is wrong in my opinion as all traces should begin and end in the center of a pad (common DRC practices). I also don’t understand why the pads are always donuts and not solid. it that a software option?
I have spent a lot of time fixing Gerbers from customer that had these types of donuts instead of solid pad. If this software provides an IPC-365 Netlist then these holes will be a problem based on my experience. I do understand that visually some people might want to see the holes in the pads to represent the drills but I am use to just turning on the drill layer when I want to see the whole picture.
Hopefully I am not too off track on this posting…
Respectfully,
DiodeDave
@DiodeDave It is not that I want the path clipped but rather that a lot of users of Fritzing are makers and a lot of makers do home etching and they want a nice round hole in the SVG and/or PDF output to center their drill. For those cases we should be doing a difference of the drill SVG from the Copper SVG giving them exactly what they want.
As for the gerber output it is good to hear that solid disks are preferable to rings. But the reason for the rings is how Fritzing works for parts creation. We create an SVG image with rings and Fritzing calculates the hole diameter you want from the SVG and then uses the SVG image as the copper component. It should not be hard to discard the inner SVG data for the rings to create a solid but again that would require someone more familiar with Object Oriented Programming than me.
The actual bug here is the result of the math being done inside a function and the same math being done to the data before sending it to the function. So my patch was to simply remove the math being done before the function and just leaving it in the function itself.
As for netlists we can currently export them in XML and SPICE but I do not know the compliance ratings for them.
@5volts I have reverted the changes making the current development version unusable and created a branch for it https://github.com/Intrinsically-Sublime/fritzing-app/tree/Testing it has the patch for this issue plus all the other small bug fixes that have been committed in the last year but without the bug that has been preventing a new version. You will still need to compile it yourself unless you are a Linux user in which case let me know and I can share the 64bit Linux Binary.
1 Like
I don’t think I could home etch with the center missing. I would need to center punch 100s of pads to guide the drill, and that would have to be inaccurately by eye. Even now the std 0.040" center isn’t accurate enough, so I put a 0.004" via on all of them.
This was done with 0.040" center holes, but If you look at the bottom row of holes on IC4 you can see what no center hole guide does.
That is why I said.
This would mean it could have no hole up until export to SVG or PDF where it could then make the holes with a difference operation.