kicad-developers team mailing list archive
Mailing list archive
Re: What's the state of the zone outline thickness stuff?
The bug was that Eagle strokes on the boundary. We stroke inside. When
we convert, we need to expand strictly as a square to get the equivalent
KiCad zone. Mitering and rounding will give excess polygon points. The
only way I have found to get this in Clipper is to use jtMiter and set
the miterlimit to 0. Oddly, just setting the parameter to jtSquare gave
a mitered corner.
It sounds from your description that you've changed this behavior in
Clipper. If that is the case, Eagle converted zones will no longer be
On 2019-07-14 14:22, Jeff Young wrote:
I looked at that bug report, and all the Eagle zones have rounded
corners, not square. So I don’t think you were actually getting
anything out of the mitering, but that was being masked by the fact
that we _do_ in fact stroke the outer zone boundary (therefore giving
you rounded corners).
Just to be clear, we stroke with the zone-min-width stroke, rather
than the zone boundary’s linewidth. We first deflate the zone by
1/2-min-width (which drops out all the min-width features), and then
stroke it with min-width which expands it back to size and gives us
some corner rounding as a bonus.
JP has recently introduced a new mode where we don’t stroke the
boundary anymore (I think primarily for performance, but I’m not
100% sure). Under this algorithm we still deflate the zones by
1/2-min-width, but we then inflate them again to bring them back to
size. My changes are largely to add corner rounding to this case.
On 14 Jul 2019, at 18:53, Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:
Please be super careful here. I was using that implicit fallback in
the Eagle import to get a square inflation that is needed to mimic
the Eagle zones. I didn't think we were using that type of
inflation anywhere else (but that could have changed). If we are
using that elsewhere, can you verify that the change to clipper
doesn't re-introduce https://bugs.launchpad.net/kicad/+bug/1817312 ?
On 2019-07-14 13:17, Jeff Young wrote:
We weren’t calling it directly anywhere. But jtMiter has a
MiterLimit, after which it falls back to square. I’ve changed
fallback to round (and enforced a much lower MiterLimit so that it
mimics the smoothing we used to get by drawing the border with a
1/2-min-width thick stroke).
On 14 Jul 2019, at 17:50, Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:
On 2019-07-14 05:31, Jeff Young wrote:
I made another optimisation, this time within the Clipper library.
When the offset exceeds the MiterLimit it will perform jtRound
of jtSquare. I *think* this makes the zero-width-border algorithm
materially indistinguishable from the old algorithm (well, except
several bugs are fixed in the new one and it’s faster).
Were we using jtSquare somewhere? I had added an option to inflate
using jtMiter but this was for Eagle import only. I thought all
other inflations were using jtRound.