Re: [Rd] mtext adj= wrong with several las= (PR#7188)
Jens Oehlschlägel wrote: No, adj moves not always along the axis: No, not yet. But mtext logically is oriented relative to its axis. And it should behave consistently relative to its axis. Whichever solution is choosen finally, I think it is important, that the default parametrisation will handle multi-line labels such that they are centered around at= and aligned at line=, whatever side= and las= are choosen. Beeing forced to tweak with adj= / padj= depending on side= / las= would be very impractical. This requirement is easily fullfilled with default adj=0.5 if we have mtext's adj= always move along the axis. With a adj= / padj= solution, different defaults would be needed for the different combinations of side= and las=. Might be nice, but I don't think we can easily change that much in mtext()'s behaviour. It is widely used in graphic functions and changing the defaults too much will break an incredible amount of code (if someone changes mtext() in that manner, I'll unsubsribe from R-help for half a year ;-)). How does it S+? The outdated S-PLUS 4.5 behaves like R does, but the logic is different since you have to specify srt rather than las. Uwe Ligges Best Jens # Thats my problem txt - This are\nfour lines\nof some\nrubish y - barplot(x, axes=FALSE, axisnames=FALSE, horiz=TRUE) # axis doesn't align it properly axis(2, label=rep(txt, 5), at=y, las=2, adj=0) # and no mtext parameters give vertically centered and right adjusted text mtext(rep(txt, 5), side=2, line=1, at=y, las=2, adj=0) __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mtext adj= wrong with several las= (PR#7188)
Hi Uwe, Thanks for your mail. I see it different: yes, Left / right adjustemnt seems to be perfectly OK. But at axis 1 with las=1, it's not Left / right adjustement what is needed here. Here the text needs to be right adjusted, and the (one) adj= par should determine the vertical alignment. It is a bit confusing, but for mtext, the distance to the axis is done via line= and adj= moves ALONG the axis, whatever las= says. I agree that it would be more flexible and logical to also have the 2 element form of adj=c(horizontal, vertical) here, but I fear that this creates a lot of incompatibilities with existing code and with S+. Best Jens Left / right adjustemnt seems to be perfectly OK. The thing that matters is centering several lines to the specified (at=) location. In fact, mtext() is not centering but bottom-aligning by adding a negative distance that looks OK for one line in the default font size, but not in most other cases. Hence this is the same as Paul Murrell's PR#1659 (mtext() alignment of perpendicular text). Fixing this, and/or improving mtext()'s adj argument to accept 2 dimensions is desirable, but might be not that easy... I'll take a look during the next days, but nothing promised. -- __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mtext adj= wrong with several las= (PR#7188)
[EMAIL PROTECTED] wrote: Hi Uwe, Thanks for your mail. I see it different: yes, Left / right adjustemnt seems to be perfectly OK. But at axis 1 with las=1, it's not Left / right adjustement what is needed here. Here the text needs to be right adjusted, and the (one) adj= par should determine the vertical alignment. I don't think so. Things are perfectly clear for the user if adj controls adjustment in reading direction independently from the las setting - and a second value specifying perpendicular adjustment. It is a bit confusing, but for mtext, the distance to the axis is done via line= and adj= moves ALONG the axis, whatever las= says. No, adj moves not always along the axis: plot(1:10) mtext(Hello, 3, at=5, adj=0, col=red) mtext(Hello, 3, at=5, adj=1, col=green) mtext(Hello, 3, at=5, adj=0, col=red, las = 2) mtext(Hello, 3, at=5, adj=1, col=green, las = 2) I agree that it would be more flexible and logical to also have the 2 element form of adj=c(horizontal, vertical) here, but I fear that this creates a lot of incompatibilities with existing code and with S+. My suggestion was different: using a new argument padj to be more flexible. Uwe Ligges Best Jens Left / right adjustemnt seems to be perfectly OK. The thing that matters is centering several lines to the specified (at=) location. In fact, mtext() is not centering but bottom-aligning by adding a negative distance that looks OK for one line in the default font size, but not in most other cases. Hence this is the same as Paul Murrell's PR#1659 (mtext() alignment of perpendicular text). Fixing this, and/or improving mtext()'s adj argument to accept 2 dimensions is desirable, but might be not that easy... I'll take a look during the next days, but nothing promised. -- __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mtext adj= wrong with several las= (PR#7188)
No, adj moves not always along the axis: No, not yet. But mtext logically is oriented relative to its axis. And it should behave consistently relative to its axis. Whichever solution is choosen finally, I think it is important, that the default parametrisation will handle multi-line labels such that they are centered around at= and aligned at line=, whatever side= and las= are choosen. Beeing forced to tweak with adj= / padj= depending on side= / las= would be very impractical. This requirement is easily fullfilled with default adj=0.5 if we have mtext's adj= always move along the axis. With a adj= / padj= solution, different defaults would be needed for the different combinations of side= and las=. How does it S+? Best Jens # Thats my problem txt - This are\nfour lines\nof some\nrubish y - barplot(x, axes=FALSE, axisnames=FALSE, horiz=TRUE) # axis doesn't align it properly axis(2, label=rep(txt, 5), at=y, las=2, adj=0) # and no mtext parameters give vertically centered and right adjusted text mtext(rep(txt, 5), side=2, line=1, at=y, las=2, adj=0) -- Supergünstige DSL-Tarife + WLAN-Router für 0,- EUR* Jetzt zu GMX wechseln und sparen http://www.gmx.net/de/go/dsl __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mtext adj= wrong with several las= (PR#7188)
Paul Murrell wrote:
Hi
Uwe Ligges wrote:
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Dear all,
Our quite basic function mtext() does wrong adjustments in some
parameter
configurations. This gets obvious when using multi line texts: There
is no
way to properly adjust text perpendicular to axis 2, for example.
Best
Jens Oehlschlägel
m - matrix(1:9, 3)
colnames(m) - c(several\nlines, several\nlines, several\nlines)
par(mfrow=c(2,2))
barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=las=0
adj=0.5 is
fine)
mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=0,
adj=0.5)
barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=las=0
adj=1 is
different)
mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=0,
adj=1)
barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=las=1
adj=0.5 is
NOT fine)
mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=1,
adj=0.5)
barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=at las=1,
adj=1
works the wrong direction, sub=no way to get adj=c(1, 0.5) with
las=1 (or
2))
mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=1,
adj=1)
par(mfrow=c(1,1))
Left / right adjustemnt seems to be perfectly OK.
The thing that matters is centering several lines to the specified
(at=) location.
In fact, mtext() is not centering but bottom-aligning by adding a
negative distance that looks OK for one line in the default font
size, but not in most other cases.
Hence this is the same as Paul Murrell's PR#1659 (mtext() alignment
of perpendicular text). Fixing this, and/or improving mtext()'s
adj argument to accept 2 dimensions is desirable, but might be not
that easy... I'll take a look during the next days, but nothing
promised.
Uwe Ligges
Having looked into the code, there are three possible solution (all with
some drawbacks) I can see. Well, the current argument adj becomes
xadj in the C sources (graphics.c, GMtext), and yadj is set to 0.
Hence the ugly hard coded LineBias of 0.3.
Solutions
=
1: Hardcode yadj to 0.5 and remove all those 0.3 biases. Looks good
for axes, but it might break some code -- bad.
On the other hand, GMMathText has hardcoded yadj=0.5. Is there a
problem with some special devices? Or any other reason not to center
stuff using adj=0.5?
2: Allow the typical 2-value adj, take the first as xadj, the second one
as yadj. This might break some code, because currently adj of
arbitrary length (!=0) is allowed and recycled.
3: Invent an argument padj for mtext() that represents adjustment
*p*erpendicular to the text direction and gets mapped to yadj in
GMtext. In that case the hardcoded 0.3 bias mentioned above can be
removed. The question is whether to set the default to 0.5 (will still
break code, but easily to fix by setting padj to 0).
I'd like to propose the third solution and would be happy to provide a
patch of GMText, including corresponding patches to GMMathText, as
well as mtext(), title() and axis() (and their inderlying do_*
components).
Are there any objections? Any reasons not to do it?
It hurts my head to think about this stuff. There are so many
combinations to worry about:
(i) The las setting
(ii) The axis (bottom, left, top, right)
(iii) Whether adj has been specified
(iv) Whether the text is multi-line
I think mtext() does ok as long as adj is not specified and the text is
single-line.
Unfortunately it does *not* (using axis() here for simplicity):
plot(1:10)
axis(3, cex.axis=5, las=2)
I would suggest addressing the multi-line problem for unspecified adj as
a first step. And I will definitely not mourn the passing of the 0.3
constant. Setting yadj to 0.5 is not enough though because that doesn't
make sense for multi-line text that is parallel to an axis (in that
case, yadj should probably be 0 for axis 2 and 3 and 1 for axis 1 and 4;
did I mention that there are lots of combinations to worry about?).
I think most of the stuff is already quite pretty.
The point is whether we are going to distinguish cases for
(p)adj={0,0.5,1} automatically or not. If the latter, we can omit
several of the cases mentioned above in (i)-(iv).
I think - as the first step - we should set the default to center (note
that text() does so as well), and let the user change padj for
multi-line text as required.
I'll try to provide a collection of patches as a proposal within, say,
two weeks.
Uwe
For user-specified adj, I agree that a 2-value adj is not a good
solution (adj is assumed to be horizontal adjustment) so maybe a padj
would be best to allow user control of vertical alignment.
Paul
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mtext adj= wrong with several las= (PR#7188)
Hi
Uwe Ligges wrote:
Paul Murrell wrote:
Hi
Uwe Ligges wrote:
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Dear all,
Our quite basic function mtext() does wrong adjustments in some
parameter
configurations. This gets obvious when using multi line texts:
There is no
way to properly adjust text perpendicular to axis 2, for example.
Best
Jens Oehlschlägel
m - matrix(1:9, 3)
colnames(m) - c(several\nlines, several\nlines, several\nlines)
par(mfrow=c(2,2))
barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=las=0
adj=0.5 is
fine)
mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=0,
adj=0.5)
barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=las=0
adj=1 is
different)
mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=0,
adj=1)
barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=las=1
adj=0.5 is
NOT fine)
mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=1,
adj=0.5)
barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=at las=1,
adj=1
works the wrong direction, sub=no way to get adj=c(1, 0.5) with
las=1 (or
2))
mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=1,
adj=1)
par(mfrow=c(1,1))
Left / right adjustemnt seems to be perfectly OK.
The thing that matters is centering several lines to the specified
(at=) location.
In fact, mtext() is not centering but bottom-aligning by adding a
negative distance that looks OK for one line in the default font
size, but not in most other cases.
Hence this is the same as Paul Murrell's PR#1659 (mtext() alignment
of perpendicular text). Fixing this, and/or improving mtext()'s
adj argument to accept 2 dimensions is desirable, but might be not
that easy... I'll take a look during the next days, but nothing
promised.
Uwe Ligges
Having looked into the code, there are three possible solution (all with
some drawbacks) I can see. Well, the current argument adj becomes
xadj in the C sources (graphics.c, GMtext), and yadj is set to 0.
Hence the ugly hard coded LineBias of 0.3.
Solutions
=
1: Hardcode yadj to 0.5 and remove all those 0.3 biases. Looks good
for axes, but it might break some code -- bad.
On the other hand, GMMathText has hardcoded yadj=0.5. Is there a
problem with some special devices? Or any other reason not to center
stuff using adj=0.5?
2: Allow the typical 2-value adj, take the first as xadj, the second one
as yadj. This might break some code, because currently adj of
arbitrary length (!=0) is allowed and recycled.
3: Invent an argument padj for mtext() that represents adjustment
*p*erpendicular to the text direction and gets mapped to yadj in
GMtext. In that case the hardcoded 0.3 bias mentioned above can be
removed. The question is whether to set the default to 0.5 (will still
break code, but easily to fix by setting padj to 0).
I'd like to propose the third solution and would be happy to provide a
patch of GMText, including corresponding patches to GMMathText, as
well as mtext(), title() and axis() (and their inderlying do_*
components).
Are there any objections? Any reasons not to do it?
It hurts my head to think about this stuff. There are so many
combinations to worry about:
(i) The las setting
(ii) The axis (bottom, left, top, right)
(iii) Whether adj has been specified
(iv) Whether the text is multi-line
I think mtext() does ok as long as adj is not specified and the text
is single-line.
Unfortunately it does *not* (using axis() here for simplicity):
plot(1:10)
axis(3, cex.axis=5, las=2)
Good point :)
I would suggest addressing the multi-line problem for unspecified adj
as a first step. And I will definitely not mourn the passing of the
0.3 constant. Setting yadj to 0.5 is not enough though because that
doesn't make sense for multi-line text that is parallel to an axis (in
that case, yadj should probably be 0 for axis 2 and 3 and 1 for axis 1
and 4; did I mention that there are lots of combinations to worry
about?).
I think most of the stuff is already quite pretty.
The point is whether we are going to distinguish cases for
(p)adj={0,0.5,1} automatically or not. If the latter, we can omit
several of the cases mentioned above in (i)-(iv).
I think - as the first step - we should set the default to center (note
that text() does so as well), and let the user change padj for
multi-line text as required.
I think the ideal would be to set padj automatically for multi-line text
as well as single-line text (the current behaviour tries to set padj
automatically for single-line text; it's just not very good at it :).
But whatever first step is good; then we can more easily discuss actual
behaviour and code examples.
I'll try to provide a collection of patches as a proposal within, say,
two weeks.
Great (modulo version scheduling issues discussed elsewhere).
Thanks Uwe!
Paul
For user-specified adj, I agree that a 2-value adj is not a good
solution (adj is assumed to be horizontal adjustment) so maybe a padj
would
Re: [Rd] mtext adj= wrong with several las= (PR#7188)
Paul Murrell [EMAIL PROTECTED] writes: I think the ideal would be to set padj automatically for multi-line text as well as single-line text (the current behaviour tries to set padj automatically for single-line text; it's just not very good at it :). But whatever first step is good; then we can more easily discuss actual behaviour and code examples. A somewhat uninformed conjecture: You'll need to look at the TeXbook again. Think of it like this: A single line of text forms a box that has a top, a bottom, and a baseline, and you can align on either or on some fraction between top and bottom. Multiple lines form a box too, but you need a way to specify whether the baseline of the entire box is defined by the top or the bottom line inside of it. In addition, you need to specify alignment inside the box. Basically, we need a more structured approach than a bunch of options that change meaning depending on the setting of other options. -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mtext adj= wrong with several las= (PR#7188)
Hi Uwe Ligges wrote: [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Dear all, Our quite basic function mtext() does wrong adjustments in some parameter configurations. This gets obvious when using multi line texts: There is no way to properly adjust text perpendicular to axis 2, for example. Best Jens Oehlschlägel m - matrix(1:9, 3) colnames(m) - c(several\nlines, several\nlines, several\nlines) par(mfrow=c(2,2)) barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=las=0 adj=0.5 is fine) mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=0, adj=0.5) barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=las=0 adj=1 is different) mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=0, adj=1) barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=las=1 adj=0.5 is NOT fine) mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=1, adj=0.5) barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=at las=1, adj=1 works the wrong direction, sub=no way to get adj=c(1, 0.5) with las=1 (or 2)) mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=1, adj=1) par(mfrow=c(1,1)) Left / right adjustemnt seems to be perfectly OK. The thing that matters is centering several lines to the specified (at=) location. In fact, mtext() is not centering but bottom-aligning by adding a negative distance that looks OK for one line in the default font size, but not in most other cases. Hence this is the same as Paul Murrell's PR#1659 (mtext() alignment of perpendicular text). Fixing this, and/or improving mtext()'s adj argument to accept 2 dimensions is desirable, but might be not that easy... I'll take a look during the next days, but nothing promised. Uwe Ligges Having looked into the code, there are three possible solution (all with some drawbacks) I can see. Well, the current argument adj becomes xadj in the C sources (graphics.c, GMtext), and yadj is set to 0. Hence the ugly hard coded LineBias of 0.3. Solutions = 1: Hardcode yadj to 0.5 and remove all those 0.3 biases. Looks good for axes, but it might break some code -- bad. On the other hand, GMMathText has hardcoded yadj=0.5. Is there a problem with some special devices? Or any other reason not to center stuff using adj=0.5? 2: Allow the typical 2-value adj, take the first as xadj, the second one as yadj. This might break some code, because currently adj of arbitrary length (!=0) is allowed and recycled. 3: Invent an argument padj for mtext() that represents adjustment *p*erpendicular to the text direction and gets mapped to yadj in GMtext. In that case the hardcoded 0.3 bias mentioned above can be removed. The question is whether to set the default to 0.5 (will still break code, but easily to fix by setting padj to 0). I'd like to propose the third solution and would be happy to provide a patch of GMText, including corresponding patches to GMMathText, as well as mtext(), title() and axis() (and their inderlying do_* components). Are there any objections? Any reasons not to do it? It hurts my head to think about this stuff. There are so many combinations to worry about: (i) The las setting (ii) The axis (bottom, left, top, right) (iii) Whether adj has been specified (iv) Whether the text is multi-line I think mtext() does ok as long as adj is not specified and the text is single-line. I would suggest addressing the multi-line problem for unspecified adj as a first step. And I will definitely not mourn the passing of the 0.3 constant. Setting yadj to 0.5 is not enough though because that doesn't make sense for multi-line text that is parallel to an axis (in that case, yadj should probably be 0 for axis 2 and 3 and 1 for axis 1 and 4; did I mention that there are lots of combinations to worry about?). For user-specified adj, I agree that a 2-value adj is not a good solution (adj is assumed to be horizontal adjustment) so maybe a padj would be best to allow user control of vertical alignment. Paul -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 [EMAIL PROTECTED] http://www.stat.auckland.ac.nz/~paul/ __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mtext adj= wrong with several las= (PR#7188)
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Dear all, Our quite basic function mtext() does wrong adjustments in some parameter configurations. This gets obvious when using multi line texts: There is no way to properly adjust text perpendicular to axis 2, for example. Best Jens Oehlschlägel m - matrix(1:9, 3) colnames(m) - c(several\nlines, several\nlines, several\nlines) par(mfrow=c(2,2)) barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=las=0 adj=0.5 is fine) mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=0, adj=0.5) barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=las=0 adj=1 is different) mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=0, adj=1) barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=las=1 adj=0.5 is NOT fine) mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=1, adj=0.5) barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=at las=1, adj=1 works the wrong direction, sub=no way to get adj=c(1, 0.5) with las=1 (or 2)) mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=1, adj=1) par(mfrow=c(1,1)) Left / right adjustemnt seems to be perfectly OK. The thing that matters is centering several lines to the specified (at=) location. In fact, mtext() is not centering but bottom-aligning by adding a negative distance that looks OK for one line in the default font size, but not in most other cases. Hence this is the same as Paul Murrell's PR#1659 (mtext() alignment of perpendicular text). Fixing this, and/or improving mtext()'s adj argument to accept 2 dimensions is desirable, but might be not that easy... I'll take a look during the next days, but nothing promised. Uwe Ligges Having looked into the code, there are three possible solution (all with some drawbacks) I can see. Well, the current argument adj becomes xadj in the C sources (graphics.c, GMtext), and yadj is set to 0. Hence the ugly hard coded LineBias of 0.3. Solutions = 1: Hardcode yadj to 0.5 and remove all those 0.3 biases. Looks good for axes, but it might break some code -- bad. On the other hand, GMMathText has hardcoded yadj=0.5. Is there a problem with some special devices? Or any other reason not to center stuff using adj=0.5? 2: Allow the typical 2-value adj, take the first as xadj, the second one as yadj. This might break some code, because currently adj of arbitrary length (!=0) is allowed and recycled. 3: Invent an argument padj for mtext() that represents adjustment *p*erpendicular to the text direction and gets mapped to yadj in GMtext. In that case the hardcoded 0.3 bias mentioned above can be removed. The question is whether to set the default to 0.5 (will still break code, but easily to fix by setting padj to 0). I'd like to propose the third solution and would be happy to provide a patch of GMText, including corresponding patches to GMMathText, as well as mtext(), title() and axis() (and their inderlying do_* components). Are there any objections? Any reasons not to do it? Uwe Ligges version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major1 minor9.1 year 2004 month06 day 21 language R __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] mtext adj= wrong with several las= (PR#7188)
Dear all, Our quite basic function mtext() does wrong adjustments in some parameter configurations. This gets obvious when using multi line texts: There is no way to properly adjust text perpendicular to axis 2, for example. Best Jens Oehlschlägel m - matrix(1:9, 3) colnames(m) - c(several\nlines, several\nlines, several\nlines) par(mfrow=c(2,2)) barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=las=0 adj=0.5 is fine) mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=0, adj=0.5) barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=las=0 adj=1 is different) mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=0, adj=1) barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=las=1 adj=0.5 is NOT fine) mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=1, adj=0.5) barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main=at las=1, adj=1 works the wrong direction, sub=no way to get adj=c(1, 0.5) with las=1 (or 2)) mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=1, adj=1) par(mfrow=c(1,1)) version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major1 minor9.1 year 2004 month06 day 21 language R -- NEU: Bis zu 10 GB Speicher für e-mails Dateien! 1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
