Могу ли я предположить, что всегда можно открыть устройство pdf NULL в R?

Для различных функций в моем пакете cowplot мне нужно иметь возможность конвертировать графики ggplot2 в grobs с помощью функции ggplotGrob(). Известная проблема в этом контексте состоит в том, что ggplotGrob() требуется открытое графическое устройство, и в зависимости от графического устройства, открытого в данный момент, вызов этой функции создает ложный пустой график. Примеры этой проблемы см. В проблеме ggplot2 № 809 или совсем недавно проблема cowplot № 82.

Можно решить проблему, открыв устройство с нулевым pdf. См. Следующий пример:

library(ggplot2)

# make a plot
p <- qplot(1:10, 1:10)

pdf(NULL) # open NULL pdf device to absorb empty page
grob <- ggplotGrob(p) # convert plot
dev.off()

Теперь вот мой вопрос: безопасна ли последовательность pdf(NULL); ggplotGrob(...); dev.off() для использования в пакете R, или есть сценарии, при которых я не могу предположить, что pdf(NULL) будет успешным / возможным? Если такие сценарии существуют, существуют ли другие графические устройства, о существовании которых я могу предположить, и могу ли я проверить их, когда я нахожусь в ситуации, когда pdf(NULL) не будет хорошей идеей? В качестве альтернативы, как лучше всего сделать код устойчивым к потенциальному сбою вызова pdf(NULL)?

Обновление: см. Также это сообщение SO, в котором обсуждается проблема пустых страниц, но не подробно описываются безопасные методы решения проблемы.

Обновление 2: В этом комментарии говорится, что некоторые установки R не имеют функционирующий pdf(). Таким образом, кажется, что действительно не всегда возможно открыть устройство pdf NULL. Тогда возникает вопрос: как я могу обойти эту проблему?


person Claus Wilke    schedule 30.11.2017    source источник
comment
bugs.r-project.org/bugzilla/show_bug.cgi?id= 16378   -  person baptiste    schedule 03.12.2017
comment
Спасибо @baptiste! Я предполагаю, что вы сталкиваетесь с аналогичными проблемами в библиотеке egg. Что вы делаете? Используйте pdf(NULL) и надеетесь на лучшее?   -  person Claus Wilke    schedule 03.12.2017
comment
честно говоря, я отказался от этого вопроса, как и многие другие, которые были закрыты или уволены. Это звучит как разумный обходной путь.   -  person baptiste    schedule 03.12.2017


Ответы (1)


Я кратко рассмотрел это, когда вы впервые разместили это. Поскольку «pdf» отсутствует в capabilities(), он «должен» всегда работать. По крайней мере, так можно надеяться. И я попытался создать пример счетчика без доступа к X11 - и, следовательно, без метрик шрифта - но потерпел неудачу.

Я все еще вижу два обходных пути, которые всегда должны вам помочь:

  1. Используйте устройство виртуального буфера кадра в вызове R; это, например, как мы проводим обратные проверки зависимостей "без головы". Вызов становится чем-то вроде / а>:

    xvfb-run-safe --server-args = "- screen 0 1024x768x24" R CMD ... что вам нужно ...

  2. Просто скажите «нет» pdf() и используйте вместо него cairo(), который: а) заведомо работает без подключения к голове и б) предоставляется двумя разными пакетами.

person Dirk Eddelbuettel    schedule 02.12.2017
comment
Дирк, спасибо за ответ. Если бы вы видели этот комментарий, в котором говорится, что некоторые установки R не нет ли работающего pdf()? Я думаю, что решение cairo() не подходит, потому что оно создает дополнительную зависимость для моего пакета. - person Claus Wilke; 02.12.2017
comment
Честно говоря, понятия не имею. Конечно, будут некоторые установки R, в которых что-то будет сломано, поскольку люди делают самые ужасные вещи со своими системами. Возникает вопрос: систематично ли это? Не сломались бы ваши модульные тесты? Не получится ли у CRAN? И я не думаю, но, возможно, я предвзято и избалован тем, что системы, которые мы создали, исправны и работают ... - person Dirk Eddelbuettel; 02.12.2017