Feature #506

Using either map- or plot-coordinates to set the anchor point in psimage, pslegend, psscale

Added by Paul over 3 years ago. Updated over 3 years ago.

Status:ClosedStart date:2014-02-09
Priority:NormalDue date:
Assignee:Paul% Done:

100%

Category:-
Target version:Candidate for next minor release
Platform:

Description

(Note: An older issue only involved pslegend and psscale but psimage is similar and could benefit from the same solution.)

The issue is that pslegend can take either -Dx to indicate plot coordinates or -D to indicate map coordinates (which then are converted to plot coordinates using the prevailing -R -J). Unfortunately, psscale has no such option and -D is only taking plot coordinates, making -Dx not an option (we want to maintain backwards compatibility). Finally, psimage has a positioning option -C (not -D) and it only takes plot coordinates. It would be nice if these three programs would have a consistent way of specifying the anchor point in either coordinate system.

Possible solution: Introduce -Dx and -Dg in all three programs.

Implications for the three programs:

  1. pslegend: The -Dg flavor will be added. However, if no modifier is given then -Dg will be assumed as -Dx was always explicit. This will retain backwards compatibility.
  2. psscale: The new -Dg flavor will be added, giving new functionality. However, to be backwards compatible one would have to let -D imply -Dx.
  3. psimage: Replace -C with -D for consistency (but -C will remain accessible via compatibility option). The new -Dg flavor will be added, giving new functionality, while -Dx gives the old -C behavior (and -C means -Dx). Since -D is a new option in psimage we can state that -D with no modifier is interpreted as -Dg.

While this would all be backwards compatible, I don't like that the default behavior of pslegend and psimage would be to expect map coordinates and psscale would expect plot coordinates. The only way I see to be consistent across these three programs would be to change psscale's default behavior to expect map coordinates. Perhaps this can be made less troublesome by insisting that -D must be followed by either g or x. In that case old-style -D with no modifier would result in an error or warning.

Alternatively, if we are to break this one backwards compatibility then we don't even need -Dg: Simply add -Dx to psscale (and -D and -Dx to psimage).
Thoughts?

Associated revisions

Revision 12898
Added by Paul over 3 years ago

First attempt at implementing feature issue #506

Revision 12913
Added by Paul over 3 years ago

Implemented uniform -D option for psimage, pslegend, psscale; see issue #506 and #512

History

#1 Updated by Paul over 3 years ago

Note: The older issue was #349, now closed.

#2 Updated by Paul over 3 years ago

  • Tracker changed from Bug to Feature

Sorry, not a bug but a feature request...

#3 Updated by Joaquim over 3 years ago

Shower is an inspiring place.
Maybe because I'm a spoiled Windows user were we naturally expect that a 20 years old binary will still run cleanly, I value a lot the backward compatibility (and well, yes, the fact that compatibility breaks screw the automatic script Mirone machinery counts too).
So todays shower came out with this plan:

1. Detect if the anchor point is inside the page size. If not, issue a loud warning. The ideal would be to just error out but we can't because that could interfere with the -O -K machinery (but see also the psscale exception)

2. Let -Dx and -Dg exists for all 3 programs in stake here and the let the default be -Dg.

3. Because the above breaks the psscale compatibility we'll do some magic guessing work to minimize the pain.

a) -D alone will try to mean old behavior (paper coordinates) UNDER THE CONDITION THAT:
- The anchor point is within a certain distance, say 5 cm, of any of the WESN axes.
Either in or the out side. The idea of this is that almost all old scripts would
fall inside this test category.
- If the above fails, try to interpret anchor coordinates as map coordinates.
If it falls inside the padding zone, fine, use it.
- If all the above falls outside the padding zone just stop and tell the user to
be explicit in his/her -D intent.
b) In any of the a) cases issue a clear warning that guessing work was done and insist
that users should use the new syntax.

Alternatively, apply this solution and put the burden of the backward compatibility break on pslegend that is a much less used program than psscale

#4 Updated by Paul over 3 years ago

  • Status changed from New to In Progress

I agree showers are good and even have other purposes than thinking about GMT, such as cleanliness, etc. But I digress...
I had the same ideas in the car this morning (no shower installed, yet). I also do not like such a dramatic incompatibility as the initial suggestion would imply, and some smarts could deal with 99% of the cases as you outlined. Any -D without x|g will give a warning and we do the best we can. I'd like Remko to opine on this as well before taking action.

#5 Updated by Remko over 3 years ago

No shower either. Maybe a shower will get me to change my mind.

While I like Joaquim's idea of logic deduction what would be the user intent, it will be very hard, if not impossible to implement. Note that we do (no longer) keep track of the "bounding box", all that code has been stripped. So we actually do not "know" where the WESN boundaries are, except if we have -R -J at hand.

I think there are some easier ways to make a pretty good feel for user intent
  1. If the user uses -Dx assume plot coordinates
  2. If the user uses -Dg assume map coordinates and require -R -J
  3. If the user uses units for the position, like 4c/-2c for x and y position, then you're sure that they are plot coordinates. It always bothered me that pslegend wanted the -Dx and could not simply understand my -D with centimeters.
  4. If the user does not use -R -J then the coordinates are always plot coordinates.
  5. Otherwise we just have to assume map position.
So how does this help us with the implementation?
  • pslegend: -D will be interpreted as above, which is totally backward compatible, because -D used to always require -R -J and would never have units. So only case (5) applies.
  • psscale: -D was all there was and implied plot coordinates. One would only use -R -J in combination with -p, a rare event. If we follow my 5-step plan above then you will end up with plot coordinates either because of (3) or (4). Non-backwards compatibility would only happen for users not supplying a unit and supplying the -R -J (needlessly or in conjunction with -p)
  • psimage: Clearly -C will mean -Dx, and -D did not exist, so there is no backward compatibility issue. But still we can use the same 5-step plan for just -D, consistently with all else.

In conclusion, the 5-step plan can be use consistently between all three programs with only a very minor chance of incompatibility (psscale with -R -J and -D without units). And no need for different treatment by different programs.

#6 Updated by Joaquim over 3 years ago

Remko, in my shower there were always frame axes easy to spot (the tiles?) but you are right, we can't be sure where there are and in fact they can even not exist at all (a single psscale call).
Your solution is simply good.

#7 Updated by Paul over 3 years ago

I like. So we will send the design to the unpaid hundreds of GMT underlings doing the actual coding.
In other words, I'll do this as soon as I find time,
Thanks!

#8 Updated by Remko over 3 years ago

Can you also ask your 100 mignons to add another option, which I quite often would have liked to exist?

-Df: use position as a fraction of the frame size, i.e. 0.5/0.5 is the center of the plot frame. Requires -R -J.

This can be handy if you want to plot a legend in the top right corner (1.0/1.0) without having to bother with checking (or even knowing) the actual dimensions of the plot. This is practical for automated plot generation. The -Bafg without values was also one of those things that was spurred in a similar way.

#9 Updated by Joaquim over 3 years ago

Remko, not exactly what you are asking but on the same spirit. pstext -F+c<justify> gets the info from -R to plot a text on the corners.

#10 Updated by Remko over 3 years ago

Yes, I know that. But here I was thinking about placing the text box of pslegend or the image from psimage in a corner, or the center, or wherever in proportion to the frame.

#11 Updated by Florian over 3 years ago

This can be handy if you want to plot a legend in the top right corner (1.0/1.0) without having to bother with checking (or even knowing) the actual dimensions of the plot. This is practical for automated plot generation. The -Bafg without values was also one of those things that was spurred in a similar way.

Yes, this option would be really beneficial!

#12 Updated by Paul over 3 years ago

Perhaps we could introduce -Dj<justify>, i.e.
-DjTC
I can see that being a practical solution. Do we really need a full fractional option for continuous 0-1,0-1? I am not arguing strongly against that, since we have a mandate from the US congress to be flexible (a rule not applicable to congress itself, of course) we could also please you guys by adding -Df<rx>/<ry> as well.

So -D[x|f|g|j]<position>[<otherargs>]

with <position> either plot coordinates, map coordinates, normalized coordinates, or justification code.

Win/win?

#13 Updated by Remko over 3 years ago

It is just that with your suggestion of -Dj the syntax will be quite different for psscale that also has length and width of the bars, and for pslegend it even becomes confusing as there is already a justification part in the -D-syntax. I think my suggestion of -Df is just more simple to explain and implement, and it keeps the parallel syntax between psimage, pslegend and psscale.

Otherwise, I would be able to understand pslegend -DjTR/3c/0c/TR
But let's not expect too much flexibility from those gremlins that you are harbouring to do the coding.

#14 Updated by Paul over 3 years ago

Implemented -D[g|n|x]<x0>/<y0>... in r12898. Sorry, tested yet (but compiles!)

#15 Updated by Paul over 3 years ago

  • Status changed from In Progress to Resolved

I have implemented a uniform -D option throughout these programs today. It looks like

-D[g|j|n|x]<anchor>/[otherthings]

where you can specify your anchor point x0,y0 without having -R -J using -Dx (or -D if your positions have units); otherwise you can use -R -J to set the anchor via normalized coordinates (-Dn), map coordinates (-Dg) or justification code relative to map frame (-Dj). If -Dj is used an no justification is specified for the bar, legend, or image, then you get a smart justify (mirror justification for psscale and same justification for images and legends). All three now have the optional dx/dy offsets away from the anchor that pslegend already had. I tested psimage pretty carefully, did some testing with psscale, but nothing with pslegend where there were hardly any changes. In r12913.

#16 Updated by Paul over 3 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100

Closing this as implemented.

Also available in: Atom PDF