Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a theme that use LaTeX fonts for everything #3147

Closed
wants to merge 18 commits into from

Conversation

Kolaru
Copy link
Contributor

@Kolaru Kolaru commented Aug 12, 2023

Description

Most issues are asking to have the sans serif Makie font in LaTeX formulas, this PR only fix the font discrepency issue by putting the LaTeX font everywhere with the new theme.

A prototype fix for the problem in the other direction should come relatively soon.

With the theme I get that kind of results
image

Type of change

Delete options that do not apply:

  • New feature (non-breaking change which adds functionality)

Checklist

  • Added an entry in NEWS.md (for new features and breaking changes)
  • Added or changed relevant sections in the documentation
  • Added unit tests for new algorithms, conversion methods, etc.
  • Added reference image tests for new plotting functions, recipes, visual options, etc.

@jkrumbiegel
Copy link
Collaborator

I like the idea, maybe it's a good opportunity to show in the docs that you can merge themes. So we could call the theme theme_latexfonts and merge it once into the default and once into a dark theme or so to show how it works.

@jkrumbiegel
Copy link
Collaborator

In your docs examples, better use with_theme to apply the themes only in a block, or reset to default at the end by calling set_theme!() # hide. Otherwise the theme changes might affect following examples

@Kolaru
Copy link
Contributor Author

Kolaru commented Aug 19, 2023

I simply don't understand the doc build failure for docs/documentation/theming.md. It complains that @L_str is unavailable, but it should be available from using CairoMakie (and it is the same as in docs/documentation/latex.md anyway).

(also building the doc locally for either this branch or master error for me -- a different error, maybe because I'm on Windows. That's a separate issue, but it doesn't help)

@jkrumbiegel
Copy link
Collaborator

Hm I didn't have these macro issues in the docs in a while, but last time it was some Franklin weirdness that I couldn't really understand.

@SimonDanisch
Copy link
Member

Ok, I'm giving up... No idea why the @L_str works anywhere else, but not here...

@SimonDanisch
Copy link
Member

I don't really know what to do here... I really don't want to start debugging franklin, and I really don't want this PR to rot, just because of a Franklin bug...
@Kolaru can we somehow change the docs in a way, that it doesn't need the latex label for now? 😓

@jkrumbiegel
Copy link
Collaborator

Yeah this is really strange.. @tlienart just FYI this is one of those cases where we assume Franklin is doing something which messes with evaluation. But we can't be sure 🤷‍♂️

@Kolaru
Copy link
Contributor Author

Kolaru commented Aug 24, 2023

It would be a bit unfortunate to not have a LaTeX string as it shows the theming is consistent.

But that's a minor thing, I'll change it before we all succumb to madness.

@tlienart
Copy link
Contributor

tlienart commented Aug 24, 2023

I'll try to look into this. Note that it's a somewhat indirect Franklin bug; if you just execute a direct cell block with a LaTeXString in it, it will work fine (namely this code works fine:

```!
using CairoMakie
CairoMakie.activate!() # hide
using Makie.LaTeXStrings # hide

f = Figure()
for i in 1:2, j in 1:2
    lines(f[i, j], cumsum(randn(50)))
end
Label(f[0, :], "A simple example plot")
Label(f[3, :], L"Random walks $x(t_n)$")
f
```

however in the docs you do (much) more than this with the examplefigure environment, and somewhere between the internal calls, something goes awry; I'll see if I can figure out what's the issue there.

@tlienart
Copy link
Contributor

do you know which example fails? because this seems to work fine too:

\begin{examplefigure}{}
```julia
using CairoMakie
CairoMakie.activate!() # hide
using Makie.LaTeXStrings # hide
function example_plot()
    f = Figure()
    for i in 1:2, j in 1:2
        lines(f[i, j], cumsum(randn(50)))
    end
    Label(f[0, :], "A simple example plot")
    Label(f[3, :], L"Random walks $x(t_n)$")
    f
end

example_plot()
```
\end{examplefigure}
Screenshot 2023-08-24 at 14 53 01

@tlienart
Copy link
Contributor

tlienart commented Aug 24, 2023

I can build the whole page fine, apart from an error halfway which seems to be on your side with a non-existent figure everything else seems fine:

Theming.pdf

the above seems to suggest that it's may not just be a simple issue with Franklin.

Could one of you try to build the docs locally and report what you see when you do serve(clear=true), if it produces the same error message? (I could try this myself but the repo is gigantic and I don't have a very good internet connection ...)

@tlienart
Copy link
Contributor

tlienart commented Aug 24, 2023

Ok I won't be able to do much more digging just now but this repo: https://github.com/tlienart/ftest-makie basically is just your theming.md; I can build it locally without issue but it fails to be deployed with the same issue you observed (here: https://github.com/tlienart/ftest-makie/actions/runs/5964248687/job/16179044884 ; it looks like it worked because I didn't toggle fail_on_warning)

Failures at deployment stages are harder to fix because we need to figure out exactly what's happening on a github instance and why things aren't the same as locally... It might be helpful if you can confirm that you can indeed build that repo above locally without issue and that you see the figures as expected (e.g. if one of you is on Linux for instance as I'm on a mac).

Not sure what could cause this; does Makie expect specific dependencies around LaTeX stuff that might not be available on a GitHub machine for instance?

@SimonDanisch
Copy link
Member

Thanks for looking into this! I can indeed build it locally with fail_on_warning = false, but I get these warnings:
image
Interestingly enough, the page that gets served in the end seems to have all examples looking correctly?
image

@tlienart
Copy link
Contributor

tlienart commented Aug 25, 2023

Ok I think I found a workaround, can you adapt your utils taking L28 from https://github.com/tlienart/ftest-makie/blob/main/utils.jl (I think if that line was just using Makie.LaTeXStrings it would probably be enough)

That seems to be the problem, the code in examplefigure is not run in an environment that has the right using (somehow). I don't have the full picture in my head but changing that seems to fix the issue:

https://github.com/tlienart/ftest-makie/actions/runs/5968808262/job/16193413162#step:4:1

@jkrumbiegel
Copy link
Collaborator

I have a theory, it probably really is about the begin block. It seems that a using inside a top-level begin cannot supply macros for resolving the same block. Which makes sense, I guess?

Here's an experiment in a new session with LaTeXStrings installed.

image

The first statement fails at load time, so the second one also doesn't work because using hasn't run yet. The third one is a single REPL command, but not a begin block, so there it works, probably because Julia executes each top-level statement one-by-one and after the first one, the macro in the second can be resolved.

So we might only have seen this error whenever a macro was used in the first cell of a page.

@jkrumbiegel
Copy link
Collaborator

Although, looking at the file in this PR again, the example added is not the first on the page, and there are even other L strings on that page before it. Including in the first cell...

@tlienart
Copy link
Contributor

I'm not sure what your last comment refers to but, your previous comment about using in begin makes sense; so a straightforward way to get this fixed and merge this PR is to adjust env_examplefigure to remove the lines of code that start with using or import and shove those before the __result assignment.

@SimonDanisch SimonDanisch mentioned this pull request Aug 25, 2023
@SimonDanisch
Copy link
Member

I think I tried that in #3180, but maybe I did something wrong...
Closing this in favor of the new pr.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants