Julia Makie `resolution` depreciated.

[agerlach]

quarto-cli/src/resources/jupyter/lang/julia/setup.jl

Line 58 in a2b6663

CairoMakie.update_theme!(resolution=(fig_width, fig_height))

Makie recently made a release that adds High DPI support (#2544 & #2346) which depreciates resolution in favor of size. I suspect this change will be positive for Quarto integration. See their blog post for additional details as the breaking change if more than just changing the kwarg name.

Currently, setting resolution overrides the High DPI upgrades. A depreciation warning is shown, but doesn't appear in final documents by default.

A current work around is to reset the Makie theme to the default via set_theme!()

[cscheid]

Thanks, that's good to know.

We probably will need to be careful. At the very least, we'd add version checks for the time being, since I don't think we can assume everyone will have instantly updated to 0.20

[agerlach]

I was having some issue today reproducing results I had yesterday using GLMakie + Quarto. Running some tests I had added CairoMakie to my Project.toml but was suprised to find changes even though I didn't ever load CairoMakie. One issue with the current setup.jl is that it loads CairoMakie and changes the default theme just based on it being available in the environment.

So, when CairoMakie is not in the environment everything is fine. But when it is the theme is overridden and the Makie warning isn't shown as execute: warning is false by default. I only uncovered the issue after opening the ipynb and seeing the warning.

[cscheid]

I was having some issue today reproducing results I had yesterday using GLMakie + Quarto. Running some tests I had added CairoMakie to my Project.toml but was suprised to find changes even though I didn't ever load CairoMakie. One issue with the current setup.jl is that it loads CairoMakie and changes the default theme just based on it being available in the environment.

So, when CairoMakie is not in the environment everything is fine. But when it is the theme is overridden and the Makie warning isn't shown as execute: warning is false by default. I only uncovered the issue after opening the ipynb and seeing the warning.

I'm trying to understand the context here. Do I understand correctly that this is unrelated to the resolution deprecation?

[agerlach]

My apologies for my confusing comment.

The depreciation of resolution in favor of size is for Makie, including all backends (CairoMakie, GLMakie, WGLMakie,...). In the current release, setting resolution will ignore size and will fallback to the old implementation in order to not be breaking with the following warning

┌ Warning: Found resolution in the theme when creating a Scene. The resolution keyword for Scenes and Figures has been deprecated. Use Figure(; size = ... or Scene(; size = ...) instead, which better reflects that this is a unitless size and not a pixel resolution. The key could also come from set_theme! calls or related theming functions.
└ @ Makie ~/.julia/packages/Makie/6NLuU/src/scenes.jl:220

Note how Quarto's setup.jl updates the theme to set the resolution

quarto-cli/src/resources/jupyter/lang/julia/setup.jl

Line 58 in a2b6663

CairoMakie.update_theme!(resolution=(fig_width, fig_height))

This line is contained in a try-catch block that calls import CairoMakie.

So, if a user uses the following in Quarto, the output will actually depend on if they have CairoMakie available in the environment.

using GLMakie # NOTE NOT CairoMakie

f = Figure(size = (100,100))

If CairoMakie is not available the try block fails on import CairoMakie and the theme is not updated w/ resolution. However, if CairoMakie is available then the theme is updated regardless of if the user explicitly loads it and all plots will ignore size and fallback to the old depreciated implementation. This happens silently because the depreciation warning is not included in the final output since execute: warning is false by default in Quarto.

I will try to put together a MWE that illustrates this.

[cscheid]

I understand you now.

Since you have more experience with Makie than we do, would you be willing to write a PR that addresses these issues in a way that works for 0.20.0 and doesn't for 0.19.0? I'd be more than happy to help you on the Quarto side.

[agerlach]

MWE. no_cairomakie.pdf and with_cairomakie.pdf shows the results without and with CairoMakie in the environment, respectively.

---
title: Title
jupyter: julia-1.9
# execute: 
#   warning: true
format: revealjs
---

## Status

```{julia}
using Pkg
cd(@__DIR__)
Pkg.activate("."; io=devnull) 
# Pkg.instantiate(; io=devnull)

using GLMakie
x = rand(50)
Pkg.status()
```

## 

:::: {.columns}

::: {.column width="50%"}
### Quarto Theme
```{julia}
f, ax, p = lines(x; axis = (; title="Title", xlabel = "X label", ylabel = "Y label"),
  label = "data")
axislegend(ax)
f
```
Plotting w/o touching the Makie theme.
:::

::: {.column width="50%"}
### Default Makie Theme
```{julia}
set_theme!() # reset theme to default. Reverses Quarto setup.jl
f, ax, p = lines(x; axis = (; title="Title", xlabel = "X label", ylabel = "Y label"),
  label = "data")
axislegend(ax)
f
```
Resetting the Makie theme to Makie's default
:::
::::

no_cairomakie.pdf
with_cairomakie.pdf

[agerlach]

would you be willing to write a PR that addresses these issues in a way that works for 0.20.0 and doesn't for 0.19.0? I'd be more than happy to help you on the Quarto side.

I am happy to help. I have an idea of how to handle the various versions, but it would probably be a hack. The fact that 0.20.0 now interprets the size

of a Figure in device-independent pixels like CSS, we can display png images with the text/html MIME type, annotated with the original size via the width and height HTML attributes. (blog post)

B/c of this there may be a much better way to integrate Makie w/ Quarto. I will ping the Makie devs on Julia's slack to this issue to try to get their thoughts.

[cscheid]

it would probably be a hack

We earnestly do not mind hacks at all in Quarto as long as the improvement in user experience is worth it (and I agree with you that getting good high-DPI support would be 100% worth it!)

[mcanouil]

Side note:

This happens silently because the depreciation warning is not included in the final output since execute: warning is false by default in Quarto.

This is a bit inaccurate.
When using format: revealjs or any presentation format, both echo: false and warning: false because the focus of a presentation is usually not the code.

When using other formats such as html everything is set to true, so if warnings are emitted they are displayed.

---
title: Title
jupyter: julia-1.9
format:
  revealjs: default
  html: default
---

```{julia}
@warn "This is a warning message"
```

[agerlach]

Welp, I spent most of the day getting a working PR put together. However, unfortunately, the required corporate contributor agreement is problematic. The time and energy that it will take, from both our sides, will far outweigh the value of my contribution. If you see another path forward, let me know.

[cscheid]

Totally understood, and I apologize, I should have let you know ahead of time. It's not something we control on our end either.

[jkrumbiegel]

I can't tell what's going wrong here, what are the actual theme values for resolution that quarto sets for you? Does the wide image actually correspond to that? In principle, setting resolution should still work as before, only the effective pixel size of the output changes because the px_per_unit value is higher

[cscheid]

@jkrumbiegel (first, thanks for Makie!) By default, Quarto calls

CairoMakie.update_theme!(resolution=(fig_width, fig_height))

Where fig_width and fig_height are defaults for figure widths and heights in inches.

I'm not sure what @agerlach originally asked, but as a Quarto dev, I can tell you that what we'd like to be able to offer is "as-good-as-possible" defaults across the many different formats and configurations that Quarto covers. It seems that Quarto should be setting size and px_per_unit instead of resolution.

Final question -- and I apologize -- How should we check for the version of CairoMakie? We'd like to do the right thing for v0.20, but not break in older installs. I'm assuming the recommended way is to iterate through Pkg.dependencies() to find the correct PackageInfo entry, but I'm not an experienced Julia dev. Is there a more idiomatic way?