[Rd] Re: argument srt for mtext(); was: [R] using text on the x axis ticks rather than numbers

Marc Schwartz MSchwartz at MedAnalytics.com
Wed Sep 8 16:22:26 CEST 2004

On Wed, 2004-09-08 at 08:02, Uwe Ligges wrote:
> Marc Schwartz wrote:
> > On Wed, 2004-09-08 at 03:13, Uwe Ligges wrote:
> > 
> >>Prof Brian Ripley wrote:
> >>
> >>
> >>>On Wed, 8 Sep 2004, Prof Brian Ripley wrote:
> >>>
> >>>
> >>>
> >>>>On Wed, 8 Sep 2004, Uwe Ligges wrote:
> >>>
> >>>
> >>>[...]
> >>>
> >>>
> >>>
> >>>>>Indeed, I think it is possible to provide an srt command (e.g. in half a 
> >>>>>year for something like R-2.1.0). What is expected for "srt = 0"?
> >>>>>a) the current behaviour, i.e. srt=0 in respect to the las setting *and* 
> >>>>>the margin side to plot the text in, or
> >>>>>b) always horizontally drawn text?
> >>>>>
> >>>>>I'd vote for b).
> >>>>
> >>>>That's easy, see the precedent in
> >>>>
> >>>>
> >>>>
> >>>>>>BTW, if you want to use srt with mtext(at=) you can always use S ....
> >>>>
> >>>>S ignores las if at= is set, so srt=0 is the current default behaviour.
> >>>
> >>>
> >>>Sorry, I garbled that.  In S, srt=0 is horizontal whatever side=, and las
> >>>is always ignored.  Not that that is documented AFAICS, and it is hard to
> >>>remember ....
> >>>
> >>>[...]
> >>>
> >>
> >>Since S is different for mtext() anyway:
> >>We can say that adjustment is determined automatically by las + side, as 
> >>it already is, and has to be adapted by the user if required.
> >>
> >>Uwe
> > 
> > 
> > 
> > Perhaps this is because I have only had one cup of coffee so far this
> > morning, but is the bias at this point towards making the change or not
> > making the change? I'm a little confuzzled...
> As Brian already pointed out, you are not the only "confuzzled" one ... 
>   at least one of the other "confuzzled" people here has not decided 
> anything yet. ;-)
> If someone is going to force a decision and convinces me, I'll probably 
> try to provide a patch.
> The most problematic point (mentioned by Brian Ripley) is the automatic 
> settings of the "adj" and "padj" values (related to reading direction, 
> as of R-2.0.0 alpha). Both have good defaults for parallel and 
> perpendicular text (related to axis) now, but what happens if srt is 
> set, and in particluar what happens if
>    (srt %% 90) != 0
> My suggestion is to use the default settings for *adjustment* ("adj" and 
> "padj") derived from "las" and "side" as usual - even if *rotation* is 
> no longer derived from "las" and "side".
> Uwe

OK...well, let me think "outside the polygon" for a moment. Notice that
I did not say "box", as the shape is not quite fixed yet.... ;-)

First, I would not twist your arm on this. There is an option already
that solves the problem and provides a great deal of flexibility, as I
described in my initial reply in the r-help thread and as others have
referenced in prior posts. A new FAQ on this might not be a bad idea

Second, in scanning do_axis() in plot.c, I wonder if (in any body's
mind) it might be easier in some fashion to modify axis() by adding a
'srt' argument? The comments in the relevant sections of the switch()
code are:

	/* The order of processing is important here. */
	/* We must ensure that the labels are drawn left-to-right. */
	/* The logic here is getting way too convoluted. */
	/* This needs a serious rewrite. */

If a rewrite is to occur at some point (perhaps as a better use of
time), one could feasibly add a check such that if 'srt' is specified in
the call to axis (or perhaps the higher level plots as part of the '...'
argument), do_text() is used (with sensible defaults for 'x,' y', 'xpd',
'mar', etc.) instead of GMMathText() and/or GMtext() as it is at

Being a firm believer in Pareto's 80/20 Rule, if some sensible defaults
would help with the typical cases, one could still use the manually
coded approach with text() as per my example, where greater flexibility
is required, as is always the case with R.

On the other hand, under the 80/20 Rule, is this even worth spending a
lot of time on?

Does this make any sense?


More information about the R-devel mailing list