similar to: Re: identify.default ignores any setting of cex (PR#660)

Displaying 20 results from an estimated 30000 matches similar to: "Re: identify.default ignores any setting of cex (PR#660)"

2018 Aug 31
2
svg ignores cex.axis in R3.5.1 on macOS
????? Plots produced using svg in R 3.5.1 under macOS 10.13.6 ignores cex.axis=2.? Consider the following: > plot(1:2, cex.axis=2) > svg('svg_ignores_cex.axis.svg') > plot(1:2, cex.axis=2) > dev.off() > sessionInfo() R version 3.5.1 (2018-07-02) Platform: x86_64-apple-darwin15.6.0 (64-bit) Running under: macOS High Sierra 10.13.6 Matrix products: default BLAS:
2008 Nov 21
1
cex.lab etc. ignored in plot.ts for multiple plots (PR#13315)
Full_Name: Yan Wong Version: 2.8.0 OS: Mac OS X 10.4 Submission from: (NULL) (78.149.183.231) When plotting multiple time series in a single plot, via plot.ts(plot.type="multiple"), the cex.lab, col.lab, and font.lab arguments are ignored > plot(ts(data.frame(a=1:10, b=1:10)), plot.type="single", cex.lab=0.5, col.lab="red") #tiny red axis labels >
2004 Jul 19
1
par(cex) is ignored by persp() (PR#7113)
Full_Name: Karel 'Clock' Kulhavy Version: 1.9.0 OS: GNU/Linux Submission from: (NULL) (212.71.168.94) persp() graphing function ignores par(cex).
2001 Oct 22
1
cex/col/etc. in title(): documentation? (PR#1136)
There appears to be a mismatch between the documentation and behavior of title(), or at least a clarification is in order. The documentation says you can pass extra arguments from par() as "...". However, cex at least is ignored. Later on in the documentation it becomes clear that you can specify these extra parameters as part of a list. I wouldn't say this is necessarily a bug
2018 Sep 05
2
svg ignores cex.axis in R3.5.1 on macOS
Seems ok on my system. Axis label size changes when cex.axis does. ## tested in the middle of another long session, so many additional packages are attached, including some personal packages not available elsewhere > sessionInfo() R version 3.5.1 (2018-07-02) Platform: x86_64-apple-darwin15.6.0 (64-bit) Running under: macOS High Sierra 10.13.6 Matrix products: default BLAS:
2018 Sep 06
1
svg ignores cex.axis in R3.5.1 on macOS
On 06/09/2018 10:47, peter dalgaard wrote: > I think this needs to be taken off the bug repository and continued here. By now it seems pretty clear that this is not an R bug, but a local problem on Spencer's machine, likely connected to font configurations. Or even on R-sig-Mac. > I poked around a bit on the three Macs that I can access, and found that fc-match does different things,
2012 Sep 05
2
cex.lab ignored in plot.zoo for multiple plots
Hello everyone, a problem with the plot.zoo function. In the parameters of the function, cex.lab is ignored. I tried to reduce the size of the yaxis labels by at least 50%. ------------------ Example: sample <- as.zoo(EuStockMarkets) par(las=1) plot.zoo(sample, plot.type="multiple", main="Time Series", xlab="Date", yaxt="n", cex.lab=0.5,
2018 Aug 31
0
svg ignores cex.axis in R3.5.1 on macOS
On 2018-08-31 14:21, Spencer Graves wrote: > Plots produced using svg in R 3.5.1 under macOS 10.13.6 ignores > cex.axis=2.? Consider the following: > > > > plot(1:2, cex.axis=2) > > svg('svg_ignores_cex.axis.svg') > > plot(1:2, cex.axis=2) > > dev.off() > > sessionInfo() > R version 3.5.1 (2018-07-02) > Platform: x86_64-apple-darwin15.6.0
2002 Jun 07
1
Bug list summary (automatic post)
================================================= This is an automated summary of the status of the R-bugs repository. Note that this may be neither complete nor perfectly correct at any given instance: Not all bugs are reported, and some reported bugs may have been fixed, but the repository not yet updated. Some bug fixes are difficult to verify because they pertain to specific hardware or
2017 Aug 03
1
switch of cex adjustment with mfrow?
> use > > par(mfrow=c(2,2), cex = 1) This does work as written. But when I first checked single-call setting, an mfrow change to cex in the same call superseded cex=1; hence my suggestion to use separate calls to par(). Further checking confirms that the result of a call to par is dependent on argument specification order in the call: par(mfrow=c(2,2), cex = 1) par("cex") #
2011 May 11
1
mtext text size (cex) doesn't match plot
Hi, I am using mtext instead of the ylab argument in some plots because i want to move it away from the numbers in the axis. However, the text in the X axis, for example: par(mar=c(5, 5.5, 4, 2)); plot(data, main="plot name", xlab= 'X axis', ylab="", font=2, cex.lab=1.5, font.lab=2, cex.main=1.8); mtext('Y axis', side=2, cex=1.5, line=4,
2017 Aug 02
0
switch of cex adjustment with mfrow?
On 02/08/2017 8:29 AM, Jannis via R-help wrote: > Dear list members, > > > i am trying to create multiple figures with identical layout (i.e. font sizes etc.) for a publication created with Latex. To do so (i.e. to get identical font sizes) I save all plots as a pdf with widths and heights as they would later appear in the paper (to prevent scaling etc.). My problem now is that I
2001 Feb 22
1
cex= and plot(), title(), mtext()
using R 1.2.1 under LinuxPPC, using the default X11 graphics device, i can't get the cex= argument for plot() and title() to have any effect. works for text(), though. the text size for plot() and title() _is_ correct if par(cex=size) is called first. oddly, mtext() seems to pay attention to cex=, but to ignore the value set by par(). for example, > plot(1:5, 1:5,
2003 Mar 12
1
cex.axis in boxplot (PR#2628)
Hi, the graphical parameter "cex.axis" does not have any affect for "boxplot": data(iris) boxplot(iris[,1:4], ylab="y", cex.lab=2, cex.axis=2) The patch is simply adding "cex.axis" to the search for axis relevant parameters in "bxp": ax.pars <- pars[names(pars) %in% c("xaxt", "yaxt", "las",
2000 May 22
4
text() with large cex parameter crashes X11() (PR#553)
Trying to use text() with very large cex parameter crashes R when using the X11() device X11() plot(1,1,type="n") text(1,1,"foo", cex=10) This also crashes R points(1,1,pch="A", cex=10) presumably because we are trying to load a font that doesn't exist, but I haven't looked into it. Martyn --please do not edit the information below-- Version: platform
2002 Jul 07
1
Bug list summary (automatic post)
================================================= This is an automated summary of the status of the R-bugs repository. Note that this may be neither complete nor perfectly correct at any given instance: Not all bugs are reported, and some reported bugs may have been fixed, but the repository not yet updated. Some bug fixes are difficult to verify because they pertain to specific hardware or
2018 Sep 06
0
svg ignores cex.axis in R3.5.1 on macOS
I think this needs to be taken off the bug repository and continued here. By now it seems pretty clear that this is not an R bug, but a local problem on Spencer's machine, likely connected to font configurations. I poked around a bit on the three Macs that I can access, and found that fc-match does different things, including throwing warnings, hanging and even crashing my old MB Air... One
2012 Sep 02
2
Impact of cex changing as a function of mfrow
R 2.15.1 OS X (MLion) Colleagues, I am aware that changes in mfrow / mfcol in par() affect cex (from help: In a layout with exactly two rows and columns the base value of ?"cex"? is reduced by a factor of 0.83: if there are three or more of either rows or columns, the reduction factor is 0.66). I generate a multipage PDF in which mfrow varies such that cex is impacted. This affect
2007 Apr 28
1
Hmisc curve label size & cex
R-Masters, I need to produce high resolution line plots and place labels on the curves. It seems that cex must be high relative to the other cex values in order to produce sufficiently large & legible tick labels at high resolutions. But high cex values cause the curve labels to become gigantic when using Hmisc. I've struggled and searched the archives, but cannot find a way of
2002 Aug 21
1
Bug list summary (automatic post)
================================================= This is an automated summary of the status of the R-bugs repository. Note that this may be neither complete nor perfectly correct at any given instance: Not all bugs are reported, and some reported bugs may have been fixed, but the repository not yet updated. Some bug fixes are difficult to verify because they pertain to specific hardware or