-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reword the courtyard complexity guideline #13
Conversation
I spent a while puzzling over whether a shape met the non-intersecting requirement before realizing it's equivalent to being convex. I propose including both ways of saying it, in case the non-intersecting version is more intuitive to others.
Ah, I didn't realize that expand-polygon handles that first case. That's handy. Is there a simple way to describe the shapes that expand-polygon doesn't handle? Maybe "shapes with vertices normal to a segment (excluding its endpoints) and on the outside of that segment"? That probably belongs in the expand-polygon documentation, not horizon-pool-convention though. |
I was still underestimating the power of expand-polygon... Is this a good description of what expand-polygon can handle then?
|
expand-polygon uses clipper for polygon operations: https://github.com/horizon-eda/horizon/blob/master/src/parameter/program_polygon.cpp#L126 The only limitation from the application's point of view is that the operation results in a single polygon. |
We could explicitly state that there must be exactly one courtyard polygon, because multiple polygons will always start intersecting at some point. I haven’t checked but I can imagine the DRC complains when encountering overlapping courtyard polygons within one package. With that in place, cases like my pathological one above won’t really occur in practice and we can delete the courtyard complexity rule without substitution, I think. |
AFAIK it’s an aid to the designer to ensure assembly tolerances will not lead to problems. I’m happy to be corrected if that’s not the case, though.
This looks like what clipper/Horizon does. There only is a problem if the expansion results in a ‘hole’ in the polygon, which would, in your example, happen if the ‘corridor’ (the notch still present in the second picture) was narrower. Practically, this will be extremely rare, I think. Two courtyard polygons would be a logical way for some kind of PCB-mounted module with an additional connection somewhere else. With the connecting wire raised from the PCB, other components could be placed between the module and its extra connection. This won’t be a frequent case either, though. Whether something like this should be a single package at all is another question, too. |
As discussed in horizon-eda/horizon-pool-convention#13, it's complicated and I made some incorrect assumptions after reading this. I think making it clear here will reach anybody who goes looking. The question of how much detail to specify in horizon-pool-convention seems separate to me, because the docs for the parameter program commands should be clear on their own.
I think leaving it at "must be valid" is fine if the docs for expand-polygon are clear about what shapes produce valid expansions. I tried doing that in horizon-eda/horizon-docs#19. I think removing the courtyard complexity requirement completely would be fine too, given how hard it is to violate it. |
I’ll remove the rule completely for now, as it seems to be largely unnecessary. If we start noticing problematic PRs, we can always put it back in. |
I spent a while puzzling over whether a shape met the non-intersecting
requirement before realizing it's equivalent to being convex. I propose
including both ways of saying it, in case the non-intersecting version is more
intuitive to others.