fig-width and fig-height doesn't document units

[EmilHvitfeldt]

What would you like to do?

Report an issue on quarto.org

Description

https://quarto.org/docs/reference/cells/cells-knitr.html#figures

right now they read Default width/height for figures. I think it would be nice to include what value you could put here, it appears it only accept bare number, e.i. no 50%? same with the unit.

[bhattmaulik]

As a user of Quarto, I have read the documentation, but didn't think about this. I always assumed that on the same page, when they write about out-width, the words are "Width of the plot in the output document, which can be different from its physical fig-width, i.e., plots can be scaled in the output document. When used without a unit, the unit is assumed to be pixels. However, any of the following unit identifiers can be used: px, cm, mm, in, inch and %, for example, 3in, 8cm, 300px or 50%." So, I thought this applies to all the width and height units.

[njbart]

In my opinion, this goes beyond a mere documentation issue.

I think dimensionless numbers are consistently a bad idea, especially when the implied unit (inch) is only used by a small minority of countries (currently Liberia, Myanmar and the United States, see https://en.wikipedia.org/wiki/Metrication, citing the CIA World Factbook 2023).

I would encourage the developers of Quarto to end the use of dimensionless numbers in all contexts and instead require that quantities are always expressed as number plus unit. (The only exception, of course, would be truly dimensionless numbers, e.g., ratios).

Incidentally, this is a policy that, e.g., TeX/LaTeX as well as pandoc have followed since their inception.

[cscheid]

We're sympathetic to the problem, and know this is a considerable limitation of our configuration at the moment. I even agree with @njbart that this goes beyond a documentation issue. In fact, that's why we can't really fix it.

Unfortunately, we don't always control the downstream context in which these values are used (consider that these are sent to libraries in Python/Julia/R, etc), and so we cannot fully avoid the issue.

[njbart]

@cscheid - Thank you for your reply.

I do realize the problems, of course.

My perhaps somewhat optimistic assumption, however, is that since quarto performs extensive preprocessing anyway, it might be possible to intercept an input such as fig-width: 10cm, preprocess it, and pass it on to subsequent processing steps as fig-width: 3.937008 (implicit unit now: inches) even without changes in any of the downstream programs.

[cscheid]

and pass it on to subsequent processing steps as fig-width: 3.937008 (implicit unit now: inches) even without changes in any of the downstream programs.

That's more or less our plan. The problem is that we don't have perfect information on which units downstream programs use, and so we can't really make that decision.