Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unneeded warnings when creating plot using non-default fonts #729

Closed
yixuan opened this issue Mar 3, 2014 · 6 comments
Closed

Unneeded warnings when creating plot using non-default fonts #729

yixuan opened this issue Mar 3, 2014 · 6 comments
Milestone

Comments

@yixuan
Copy link

yixuan commented Mar 3, 2014

Take this code snippet as an example (assuming "Ubuntu" font is installed in the system):

\documentclass{article}
\begin{document}

<<dev='png'>>=
library(ggplot2)
ggplot() + geom_point(aes(x=mpg, y=wt), data=mtcars) +
    theme(text = element_text(size = 16, family = "Ubuntu"))
@

\end{document}

When compiling this with knitr, the output pdf will contain a long list of warnings similar as below:

## Warning: font family 'Ubuntu' not found in PostScript font database

However, if we call the device function directly,

png()
library(ggplot2)
ggplot() + geom_point(aes(x=mpg, y=wt), data=mtcars) +
    theme(text = element_text(size = 16, family = "Ubuntu"))
dev.off()

then there is no such warning issued.

I believe this is caused by the null graphics device pdf(NULL). From my understanding knitr will evaluate code chunk on this null device and record the plotting operations to some objects. However, pdf() only support standard fonts like "Times" and "Courier", and will yell to other fonts that it does not recognize.

The "real" null device mentioned in http://yihui.name/en/2010/12/a-special-graphics-device-in-r-the-null-device/ is already removed from R. Is there any other approach to solve this problem?

@yihui
Copy link
Owner

yihui commented Apr 14, 2014

#561 may be one approach, but I have not implemented it yet.

An inelegant solution is to set the recording device to png, e.g.

options(device = function(file, width, height) {
  png(tempfile(), width = width, height = height)
})

Maybe I should give up the idea of using the PDF null device to record graphics, but use the device specified in the dev option instead. I'll think more about this.

@yihui yihui added this to the v1.7 milestone May 25, 2014
@yihui yihui modified the milestones: v1.7, v1.8 Oct 14, 2014
@yihui yihui modified the milestones: v1.8, v1.9 Nov 26, 2014
@yihui yihui closed this as completed in bc21f08 Dec 25, 2014
@hrbrmstr
Copy link

possibly also solved by using extrafont::loadfonts() in a hidden markdown block?

@yihui
Copy link
Owner

yihui commented Feb 15, 2017

I think this specific problem has been solved long ago. When dev='png', knitr will just use a png() device to record plots instead of the null pdf() device.

@bhaskarvk
Copy link

FWIW I am still seeing this bug and I do need to use the workaround mentioned in #729 (comment)

@JerryWho
Copy link

I still have this problem, too. My problem isn't resolved with this work around. The work around seems only to work with pdflatex or lualatex. But I habe to use xelatex.
With xelatex there aren't any fonts in the graphics.
This document only gets this output

\documentclass{article}
\usepackage{graphicx}

\begin{document}
<<set-options>>=
 Sys.setenv(LANG = "en")  
 options(device = function(file, width, height) {
  png(tempfile(), width = width, height = height)
})
@
 \begin{figure}
    \centering
<<output, dev='png'>>=
library(ggplot2)
ggplot(mtcars, aes(x=wt, y=mpg, color=factor(gear))) + geom_point() +
 ggtitle('Fuel Efficiency of 32 Cars') +
 xlab('Weight (x1000 lb)') + ylab('Miles per Gallon') +
 theme(text=element_text(size=16, family='Source Code Pro'
 ))
@
   \end{figure}


\end{document}

image

(I'm using an extra example because I'm using a Mac and don't have this Ubuntu font. So I use Source Code Pro.)

yihui pushed a commit that referenced this issue Apr 18, 2019
@github-actions
Copy link

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants