-
Notifications
You must be signed in to change notification settings - Fork 87
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
'precision' parameter doesn't work as described #44
Comments
Right, thanks, of course... This should be very easy to fix though, would you like to submit a PR? |
Hm, it actually seems non-trivial to me because I don't fully understand the code in the Also digging more into So I think I'll leave this one to you. I might take a shot at a PR for one or both of the other two earlier issues (#45 and #46), but I can't guarantee it'll be in a timely fashion, so if you want to go ahead and quickly scratch them off, feel free. |
Concerning multiplication by 2 - keep in mind that those are lists, not arrays, and this is simply used to create pairs of coordinates of corners, not centers of bboxes. The logic is that if neither rectangle contains any corners of the the other rectangle, these rectangles don't overlap. May not be the simplest way to test this... |
You actually got me thinking, and this is not strictly true in all cases - i.e. one vertical rectangle can overlap with a horizontal one with all corners being outside. But as far as all rectangles are the same height (which is typically true), this should hold... But probably this should be generalized just in case, and simply checking for left side being to the right of the right side of the other rectangle (and same for all other sides) should be very easy and work 100%. |
As a note to my future self, this looks interesting |
Or, |
Ah, I get it, sorry I thought they were arrays when I first looked at it. That also explains the modulo! That's a good point about the corners possibly not being contained. I'm not familiar with either of those libraries, but they look promising. Presumably you could also just use the |
That's why I used this approach, but it might have been a premature optimization... |
I think this is fixed in the recent commit - the main issue reported here, that is, not the intersection algorithm. |
The docstring says...
In practice, at each iteration, precision is compared with the sum of the
q
values returned by therepel_text*
functions, and these functions seem to calculateq
as the sum of the absolute x/y displacements of texts. This is definitely not the same as the sum of the overlaps.For example, a text bbox may have an overlapping point (or text) left of its center that demands a dx of 1, and another overlapping point right of center that demands a dx of -1. Thus the net x displacement (
q
) of the text is 0, but the overlaps are not 0.The text was updated successfully, but these errors were encountered: