'precision' parameter doesn't work as described about adjusttext HOT 9 CLOSED

Right, thanks, of course... This should be very easy to fix though, would you like to submit a PR?

from adjusttext.

Hm, it actually seems non-trivial to me because I don't fully understand the code in the repel_* functions. Like, in repel_text here, I don't get why it's multiplying by two. If those are supposed to be the coords of the centre of the text bboxes, shouldn't it be dividing by 2?

Also digging more into repel_text_from_points, I think I found a bug (#49).

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.

from adjusttext.

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...

from adjusttext.

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%.

from adjusttext.

As a note to my future self, this looks interesting
https://github.com/Pithikos/python-rectangles

from adjusttext.

Or, shapely, of course - maybe all calculation should migrate to using it? Then, perhaps, we can properly support non-rectangular objects?

from adjusttext.

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 bbox.intersection method for each pair, but maybe that would be too expensive.

from adjusttext.

That's why I used this approach, but it might have been a premature optimization...

from adjusttext.

I think this is fixed in the recent commit - the main issue reported here, that is, not the intersection algorithm.

from adjusttext.