-
Notifications
You must be signed in to change notification settings - Fork 348
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
legend: clearances between legend items and the box border #4101
Comments
Currently, the default clearance is controlled by -C so if -F+c is not given then the -C defaults apply. Since we have to be backwards compatible here we will still need to honor -C and its defaults. Perhaps we simply undocument -C and transfer the default to -F+c but leave the code as is? |
I think it's a good solution. |
Reading more carefully, there seems to be a difference:
So they achieve the same relative result but in two different ways. That may be overkill but also not a duplication we can easily fix by removing -C. At best, we could add -F+Cclearance which would do the inwards shift like -C while -F+c would do the outward shift. Thoughts on this? |
Wait, perhaps I am wrong about this (or specifically the comments in the code). I see the computation of the box height starts with
so that suggests outward moving of the boundaries, just like -F+c says it does. |
No, not wrong. Here I run with -C:
Here I use -F+c:
Clearly two different effects, so perhaps the real solution here is better documentation? |
OK, now I understand the differences between these two. To me, the behavior of -C (inwards shift) seems more useful. When I use -DjBL+o0.2c/0.2+w5c, I expect to put the legend (the legend box) to the bottom left corner, with 0.2c and 0.2c offsets, but
do the outward shifts (like the figure above), then I have to change the offsets (+o modifier) based on the values of +c. |
I agree that it seems very awkward to add space with +c and then having to adjust via +o. So there are two paths:
I think option 1 is more appealing, but possibly we will ahve to deal with some test failures and PS updates. Voting on this, @seisman and @joa-quim ? |
Also prefer 1. |
Yes for option 1. |
Before we do this, let's be clear on the scope. Another difference with -C is that -F+c clearance is either gap, xgap/ygap, or lgap/rgap/bgap/tgap while -C is only gap or xgap/ygap. So allowing the 4-sided clearances requires some recoding in pslegend. Furthermore, -F also applies to many other map embellishments and it is not clear (I have not looked in detail) if what makes sense for a legend also makes sense for map scales, compasses, etc. I think we need to know that before changing -F+c due to side-effects. Checking for scripts that contain a -F option with a +c modifier and not pstext gave me these:
For instance, the agefig.sh has this:
as we try to do a good job fitting a rectangle behind a colorbar with labels. The reason for this really is that the only way to do this exactly is to do the sizing in PostScript based on things that are plotted. But it is pretty hard to keep track of min/max extents of annotations and labels. In this case, enlarging the rectangle was needed. So if we declare a but, we sould have to change the signs of those to +c0p/-1p/-2p/-8p and now it looks less appealing. Chew on this and see what you think. |
Regardless of the above, I think +oxoff/yoff should be such that the corner of the rectangle touches that point. With -F+c now it is the zero-clearance imaginary rectangle that touch that point. That could be fixed without affecting the -C discussion if we declare that a bug. Again, this then shifts the center of the rectangle so there is some other considerations as well. |
The new behavior (+c means inward offsets) may not make sense for -Dglon/lat, especially for map scale bars. |
Yes, so I think the only good solution here is to decide that -F+c will presumably extend the rectangle, and then the -F+o offset should be measured to the side/corner of that extended box, not the original one (with zero extensions). I cannot see that any user would want to get the result above (2nd hello) but would expect it to have its lower-left corner at the same spot as the first Hello, since no offset was specified. Do we all agree on that interpretation? So I think legend -C is a separate module-specific option that will stay, and the interplay between -F+o+c needs work. |
Pinging you guys again as we should wrap this up. So +c should extend the rectangle and then +o works relative to the extended rectangle. OK as a plan? |
This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions. |
Description of the problem
In the legend module, it seems the -F+c and -C options set the clearance between legend terms and the frame. Is it right? If yes, perhaps we should remove the -C option from the documentation (still keep it for backward compatibility).
Here is an example:
Removing
+c10p/10p
and adding-C10p/10p
gives similar plots.For large clearances,
+c50p/50p
still works well, but-C50p/50p
doesn't. Here is the result for-C50p/50p
.The text was updated successfully, but these errors were encountered: