similar to: Use cairo fallback resolution greater than 72dpi in cairo_pdf and cairo_ps in grDevices

The 'at a minimum' information requested by the posting guide is missing. According to their documentation the cairo default fallback resolution is now 300dpi, and when I run your example on Fedora 21 that is what the emitted postscript says it is. You can easily alter the R code to set it to something different: see http://cairographics.org/manual/cairo-cairo-surface-t.html for the

I have had some fun in the last few days trying to put together an annotated map of China with R and some public GIS data: http://sourceforge.net/projects/outmodedbonsai/files/snpMatrix%20next/1.17.7.11/China_Choropleth_Maps.pdf/download It is done, and rather nice... there are a few issues: - the default pdf() device cannot do CJK with embedded fonts - and cairo_pdf() is not hooked up to

It was as easy as I thought it was half a day ago - here is a patch against R trunk to add cairo support to the Sweave driver, an example Sweave input, and the resulting output. A few more notes: - obviously the documentation needs to be updated... a bit more work to do. - some check to make sure "cairo" and "pdf" are not both set would be nice, as well as checking

I was recently testing R and RStudio on a high dpi 4K monitor under Windows and noticed that the plot window cannot be scaled or zoomed without affecting the relative sizing of all plot elements (line widths, font sizes, legend spacing etc). RStudio seems to try to overcome this by enabling dpi scaling for the plot window on high dpi screens, but this results in really fuzzy text and graphics

With a default installation of R on Windows platforms, packages are stored under Program Files/R/R-3.X.X/library. This often causes permission problems, as this directory is always read only by default, requiring the user to either change permissions for that directory or to change the directory where packages are stored later on option wise through modification of .libPaths in .Rprofile. For most

Hi all, I have the following problem: Since R 3.4.0, italic fonts rendered on Cairo devices appear pixelated. Here's a minimal example: cairo_pdf('test.pdf') plot(1:10, ylab=expression(italic(test))) dev.off() The same problem occurs with bolditalic, but not bold. I am using Debian Stretch. Several friends tried the same on their machines, another Debian machine has the same

Hi all, I have the following problem: Since R 3.4.0, italic fonts rendered on Cairo devices appear pixelated. Here's a minimal example: cairo_pdf('test.pdf') plot(1:10, ylab=expression(italic(test))) dev.off() The same problem occurs with bolditalic, but not bold. I am using Debian Stretch. Several friends tried the same on their machines, another Debian machine has the same

On Mon, 30 Mar 2020 at 04:24, Paul Murrell <paul at stat.auckland.ac.nz> wrote: > > Hi > > I have created an R branch that contains a potential fix ... > > https://svn.r-project.org/R/branches/R-symfam/ > > This allows, for example, ... > > cairo_pdf(symbolfamily="OpenSymbol") > > ... to specify that the OpenSymbol family should be used as the

Hi Ilia, I'm running Arch Linux, R 3.4.0. Here's my test.pdf from your minimal example: https://ptpb.pw/HxsA.pdf It doesn't look pixelated to me... Here's a post that I wrote when I solved my last font problem in R, almost 2 years ago: https://stackoverflow.com/a/40940331/5087283 I had to install some Microsoft font packages, which is sad, because there are some perfectly

Hi Ilia, I'm running Arch Linux, R 3.4.0. Here's my test.pdf from your minimal example: https://ptpb.pw/HxsA.pdf It doesn't look pixelated to me... Here's a post that I wrote when I solved my last font problem in R, almost 2 years ago: https://stackoverflow.com/a/40940331/5087283 I had to install some Microsoft font packages, which is sad, because there are some perfectly

Interesting. I did not have the package installed, but I did at some point extract Helvetica from some MacOSX font files and R was using that just fine until 3.3. This is how the plot looks in 3.4 (still using Helvetica): https://ptpb.pw/HikX.pdf . After removing Helvetica, installing the ttf-mscorefonts-installer package, and running fc-cache --force the plot looks like this:

Dear all, For vector-based output, PDF export of R graphs works well, but unfortunately Office on Windows provide poor support for PDF and importing & exporting to other formats using Inkscape can be buggy. Enhanced metafile export in turn does not support transparency (also not in package devEMF - are there any plans to support this perhaps in the future?). And rasterising graphs to a PNG I

On Fri, Jul 07, 2017 at 07:08:52PM +0200, Ilia Kats wrote: > Interesting. I did not have the package installed, but I did at some point > extract Helvetica from some MacOSX font files and R was using that just fine > until 3.3. This is how the plot looks in 3.4 (still using Helvetica): > https://ptpb.pw/HikX.pdf . After removing Helvetica, installing the > ttf-mscorefonts-installer

Hi, Following Paul's instruction, I have installed the Cairo. I tried to run the program, and there is no error message at all. I did see the Chinese title in the plot if I ask my RStudio to show the plot (if I type "p1"), but the pdf file shows the plots without the Chinese titles. library(ggplot2) library(gridExtra) df1<-data.frame(x=1:2, y=3:4, z=5:6) #p1<-ggplot(df1,

Hi I decided to blame cairo_pdf(). There is a fix in r-devel (r72242) that works for the reported case, plus some basic sanity checks. I could not complete 'make check-devel' because it was failing on reg-tests-1d.R ... > stopifnot(length(fd) == 10, identical(fd, format(dct <- as.POSIXct(dlt)))) Error: identical(fd, format(dct <- as.POSIXct(dlt))) is not TRUE ... anyone

Hi, I wonder if this is expected or I'm doing a wrong thing. pdf() dev.control('enable') library("grid") plot(1) grid.text("A") res = recordPlot() dev.off() cairo_pdf() replayPlot(res) dev.off() *** caught segfault *** address 0x4, cause 'memory not mapped' > sessionInfo() R version 3.3.2 (2016-10-31) Platform: x86_64-apple-darwin13.4.0 (64-bit)

Hi all, I'm currently preparing some figures that will be submitted to PloS One. In their guidelines they state that they will only accept figures in tiff or eps format, with the warning that eps figures will be converted to tiff format ( see http://www.plosone.org/static/figureGuidelines.action ). Because of this conversion, I figured I'd generate tiff-format figures from the beginning.

Hi This appears to be happening (at least) because cairo_pdf() delays initialising a Cairo surface until BM_NewPage(), rather than initiliasing a Cairo surface in BM_Open(), and replayPlot() triggers some activity (set clip region) on the device BEFORE a new page is started (so the pointer to the Cairo surface is null, so BOOM). Not sure yet whether to blame replayPlot() for not starting

Hi Paul, Great, thank you for looking in to this, and I'm glad that you're able to reproduce it at your end too. From your reply, I'm happy that it seems like the fix may be fairly trivial, but I understand the necessity for caution. If there's anything else I can do to help, please do let me know. Thank you again, Best, Lee On Monday, 4 March 2019, Paul Murrell <paul at

On Mon, 30 Mar 2020 at 22:41, Paul Murrell <paul at stat.auckland.ac.nz> wrote: > > Hi > > On 30/03/20 10:43 pm, I?aki Ucar wrote: > > On Mon, 30 Mar 2020 at 04:24, Paul Murrell <paul at stat.auckland.ac.nz> wrote: > >> > >> Hi > >> > >> I have created an R branch that contains a potential fix ... > >> > >>