Sizing of *saved* figures

[tfjaeger]

This is more of a feature request / curious question (after a lot googling and reading). I've noticed that fig.width, fig.height, etc. do not seem to determine the size of figures in the files that are saved as part of knitting (in fig.path), even when taking into account dpi.

For example, for a figure for which fig.width = 10 and fig.height = 10.5 (and default 72 dpi), I'm getting a 2580 × 1440 PNG figure (at 72 dpi) from knitting. But that is a width of 35.83 in instead of 10. My colleagues and I (all working on different MacOS versions, with fully up-to-date R, RStudio, and knitr versions) all experience this issue. Indeed, I can't remember this ever not having been the case. Is there a reason, why fig.width and fig.height would not directly spell out into the dimension of the figure, like in a ggsave command?

(For context, for final journal submissions/proofs, we usually need to submit all figures separately from the knitted document. This tends to result in a hotchpotch of figure sizes in the journal proofs, undoing all of our careful work to keep panel sizes, text sizes, etc. identical across figures. We'd love to be able to tell publisher to simply print all figures at 100% of their size but that's only possible if those sizes make sense.)

Sorry, if this is a stupid question that has been answered before. But we have been unable to find any solution to this issue (short of generating all figures both through knitr and ggsave), and since it's an issue that is affecting all of our projects, I'd thought I ask for your wisdom =). Thank you for your time, and any pointer you might be able to provide!

               _                           
platform       aarch64-apple-darwin20      
arch           aarch64                     
os             darwin20                    
system         aarch64, darwin20           
status                                     
major          4                           
minor          3.0                         
year           2023                        
month          04                          
day            21                          
svn rev        84292                       
language       R                           
version.string R version 4.3.0 (2023-04-21)
nickname       Already Tomorrow            

[cderv]

Thanks for the report.

First let's not there is fig.width and fig.height, dpi but also fig.retina or fig.asp which are taken into account. The output size in document will also be out.width and out.height

• if fig.asp is specific fig.height will be calculated from fig.width https://github.com/yihui/knitr/blob/0b6bee28f590cc4a4337ab45dd26a58e63e9b426/R/utils.R#L278-L287

• if out.width or out.height is not specified, the output size in pixel will be calculated from fig.* x dpi. https://github.com/yihui/knitr/blob/0b6bee28f590cc4a4337ab45dd26a58e63e9b426/R/utils.R#L289-L295

• If fig.retina is set to different than 1, then if out.width not set then it will be computed from fig.width * dpi. And dpi will be transformed to dpi * fig.retina

So it is already quite complex to follow. There is also a specific configuration where if out.width is not set, the value is computed from DPI : https://github.com/yihui/knitr/blob/0b6bee28f590cc4a4337ab45dd26a58e63e9b426/R/output.R#L608-L609

Is there a reason, why fig.width and fig.height would not directly spell out into the dimension of the figure, like in a ggsave command?

Regarding plot saving, the chunk device is opened consideing the fig.width and fig.height but also DPI which could be modified by fig.retina https://github.com/yihui/knitr/blob/0b6bee28f590cc4a4337ab45dd26a58e63e9b426/R/block.R#L372-L377

Can you try setting fig.retina = 1 as options in your document to see if that behave more as your are expecting ?

Hope this helps understand a bit more the internals

[tfjaeger]

Thank you so much for the detailed response. We will try the retina option (I was aware of the other options and am pretty sure that they don't explain what we see, but we had not explicitly specified retina). I'll update this post once I'll have more to report.