More flexible per-visualizer `ggsave()` args and `Visualizer` filtering with `export_visualizers()`
jpdunc23 opened this issue · 4 comments
It would be nice to be able to use different settings for different visualizers, while still maintaining the ability to pass common settings for all.
It seems like the cleanest way to do this would be similar to the existing .doc_options
argument to create_visualizer()
, but more flexible in that it would cover anything that can be passed to ggsave()
, not just width
and height
. So this might also supersede .doc_options
, in which case we'd probably want the argument name to be more general, e.g. .viz_options
.
Also, limiting export_visualizers()
to save only specific Visualizer
outputs could be useful, but probably less so.
@tiffanymtang what are your thoughts? Would this play nicely with render_docs()
?
I like the idea of making export_visualizers()
such that it allows for saving only specific Visualizer
outputs.
Besides the height
and width
arguments though, do you see a use case for allowing for different per-visualizer inputs for the other ggsave
arguments? I'm not sure if there would be a clean way to enable this, since when we run render_docs()
, we don't call ggsave()
but rather use vthemes::subchunkify()
. Thus, arguments in ggsave()
which have no equivalent in vthemes::subchunkify()
may cause confusion if we were to unify this under something like .viz_options
.
Another ggsave()
argument that @PhilBoileau often uses is scale
, which to my understanding scales the size of the plotting area (but not text like axis labels / titles). This could be helpful for saving publication-quality plots directly from the experiment without having to manipulate viz_results
directly, but it doesn't seem like that particular argument is relevant for the knitr
chunk options. On the other hand, dpi
and device
(fig.dev
in chunk options) are.
I think you're probably right that unifying things under .viz_options
will just cause confusion, not to mention being harder to maintain. Maybe instead we just have a separate .ggsave_options
argument for create_visualizer()
, passed as is to ggsave()
as is and taking precedence over any of the shared settings pass via ...
to export_visualizers()
.
What expanding the possible .doc_options
? Is there's a compelling use case?
Got it ok. Well I think creating a separate .ggsave_options
is fine by me!