Yu-Group/simChef

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!