Bug 14532

Summary: axis, title & padj
Product: R Reporter: Philip Johnson <plfjohnson>
Component: GraphicsAssignee: R-core <R-core>
Status: CLOSED FIXED    
Severity: minor    
Priority: P5    
Version: R-devel (trunk)   
Hardware: All   
OS: All   
Attachments: patch to fix bug

Description Philip Johnson 2011-03-14 21:31:22 UTC
Created attachment 1185 [details]
patch to fix bug

Please see my e-mail to R-devel on 02 Mar 2011 (message copied at bottom of this bug report).  Given no replies to that message, I went ahead and implemented a fix.  In the process, I realized a flaw in the fixes I proposed in that message: using padj=1 for xlab and side 1 axis would shift position depending on the actual height of the label (e.g. "aoc" is shorter than "AOC").

I attach a patch against the current svn version of R-devel that:

1) modifies src/main/graphics.c to properly use yLineBias by:
   - taking par("mex") into account
   - applying yLineBias consistently (previously, plotmatch ignored it, so mtext with math aligned differently than mtext without)

2) modifies src/modules/X11/devX11.c to increase yLineBias to 0.4

3) modifies src/library/grDevices/src/devPS.c to increase yLineBias to 0.4


This fixes the problem for X11, postscript and pdf output.  I cannot vouch for Quartz or Windows, but these should require (at most) a trivial change of yLineBias in:
  /src/library/grDevices/src/devQuartz.c
  /src/library/grDevices/src/devWindows.c

--Philip


-------triggering code below------

test <- function() {
     plot(1:10)
     sapply(1:4, function(x) (mtext("blah           ", side=x)))
     sapply(1:4, function(x) (mtext(expression(alpha), side=x)))
}

dev.new(width=9, height=3)
par(mfrow=c(1,3), cex=1)

par(mex=1.0, mar=c(4,4,2,2)); test()
par(mex=0.5, mar=c(4,4,2,2)); test()
par(mex=0.1, mar=c(10,10,10,10), las=0); test()




------original message to R-devel below------
Hi,

I often use par(mex = 0.5) as an easy way to shrink space used for margins. However, I recently noticed that this leads to an asymmetry in the positioning of the x vs. y axis labels and xlab / ylab -- the x-axis labels are pushed into the tic-marks, while the y-axis labels look fine.

A more extreme example:
dev.new()
par(mex=.1, mar=c(10,10,10,10))
plot(1:10)

Tracking this down in the code, this effect appears to be arising from:

   1. GMtext in graphics.c adjusts the margin line coordinate using dev->yLineBias. After commenting out these adjustments, the x-axis text is clearly shifted up (i.e. the bottom of the text is aligned at the specified margin line) while the y-axis text is shifted left (i.e. the bottom of the text is still aligned with the specified margin line).
   2. This observation lead me to realize that do_axis and do_title in plot.c assume padj=0 most of the time (there are exceptions depending on par()$las). 

I'm no expert in the R code base, but the yLineBias adjustments appears like they might have been intended to restore symmetry -- but it only works for mex=1.

Is there a reason why, instead of yLineBias, we can't either:

   1. center axis and title text by default (i.e. padj=0.5) -or-
   2. align side=1,3 with padj=1; side=2,4 with padj=0 ? 

Solution 1 is trivial to implement, but this would shift positioning slightly relative to the current code (even for mex=1). Solution 2 is slightly trickier because we have to pay attention to side and las values, but would not change the output for mex=1.

I implemented drafts of both solutions, which work at least superficially. Two questions:

-Am I missing a larger purpose to yLineBias?
-Thoughts about which solution is better / can I contribute a patch
to fix this?

Regards,
Philip
Comment 1 Brian Ripley 2011-03-21 12:13:15 UTC
You can't simply change the parameters of the devices to suit your
single example: they will change everyone else's output, and in
particular make it irreproducible.  This would have to be done for all devices after careful visual comparison of their output.

Even the graphics.c change affects the placing of axis annotation, so
affects almost all R plots.  And plotmath expressions and ordinary text
are not treated equivalently.

For 2.13.x all I am prepared to put it is scaling the adjustments by 'mex'.
This should affect only plots which use 'mex'.

And please do not delete other people's comments in your patch.

We can change other aspects of graphics output, but there needs to be very good
reason to do so and extensive testing prior to release.

I am closing this PR: if you want to open a wish to change other aspects, please start a new PR.