# Course about creating reports with julia

I create a little walked example through the julia package landscape for creating \LaTeX - reports with julia.
This course is targeted at physics students needing to write reports about physical experiments, but might also be useful for people in other fields.

Happy to hear your thoughts on it.

15 Likes

Looks very nice and useful. (I’m always trying to advertise the use of Unitful.jl in my group as well and will share this!)

A super tiny detail, in the first plots the unit is in ( brackets and in the later plots with manual labels it is [ brackets.

1 Like

You could use UnitfulLatexify.jl to automate the latex labels as well.

1 Like

Thank you for sharing this excellent course material.

I’ve tried to follow it using VSCode, Julia 1.8.0 on Win 11 and with MiKTeX installed, and it went more or less fine, with mistakes made on folder paths and missing loading some packages (ex: Statistics).

One issue encountered and one question:

• The LaTeX headers in the Pretty Table do not show well:

• Not clear when/how the plot recipe is used in the workflow? It seems to affect the cross-references in the text to the figures and table numbers

Fyi, here is a screenshot of the VSCode project tree:

Thanks for following it through!

The LaTeX headers in the Pretty Table do not show well

Which PrettyTables version is that? Mine was 1.3.1 on julia 1.7.3.

Not clear when/how the plot recipe is used in the workflow? It seems to affect the cross-references in the text to the figures and table numbers

That seems wierd. How exactly does it affect that? Also did you run lualatex again after the pythontex run?

For reference, my tree can be viewed here.

1 Like

This is super interesting. Thanks a lot for putting this together!
I was just wondering, is there a reason to prefer plain LaTeX over other solutions like Weave.jl or Literate.jl?

Thanks again

The main advantage is that this solution is language agnostic (up to what pythontex supports) and you have more fine grained control over the final layout (e.g. where are my pagebreaks etc.).

I never managed to create a pdf-document with the others that looked how I liked it, I’m also impatient though .
I do use Literate.jl for web related content quite often though (documentation and notebooks).

2 Likes

makes sense indeed!

Used PrettyTables v2.1.0 and Julia 1.8.0. Yes, I’ve run the sequence lualatex, pythontex, lualatex.

For the recipe question, nevermind, it does not make sense indeed.

Indeed that seems to have changed in PrettyTables:

\begin{tabular}{rrr}
\hline
\textbf{\$\textbackslash{}omega\$} & \textbf{\$\textbackslash{}omega\_m\$} & \textbf{\$\textbackslash{}omega\_\{r e s\}\$} \\\hline
21.3 MHz & 108.3 kHz & 21.1917 MHz \\
21.25 MHz & 58.4 kHz & 21.1916 MHz \\
21.22 MHz & 28.2 kHz & 21.1918 MHz \\
21.202 MHz & 9.9 kHz & 21.1921 MHz \\
21.192 MHz & 1.5 kHz & 21.1905 MHz \\\hline
\end{tabular}

(jl_jC7E1m) pkg> st PrettyTables
Status /tmp/jl_jC7E1m/Project.toml
[08abe8d2] PrettyTables v2.1.1
\begin{tabular}{rrr}
\hline\hline
\textbf{$\omega$} & \textbf{$\omega_m$} & \textbf{$\omega_{r e s}$} \\\hline
21.3 MHz & 108.3 kHz & 21.1917 MHz \\
21.25 MHz & 58.4 kHz & 21.1916 MHz \\
21.22 MHz & 28.2 kHz & 21.1918 MHz \\
21.202 MHz & 9.9 kHz & 21.1921 MHz \\
21.192 MHz & 1.5 kHz & 21.1905 MHz \\\hline\hline
\end{tabular}

(jl_aleDSv) pkg> st PrettyTables
Status /tmp/jl_aleDSv/Project.toml
⌅ [08abe8d2] PrettyTables v1.3.1

@Ronis_BR I am not sure whether this is intentional?

1 Like

Yes, this was a breaking change, sorry about that

The problem is that we must escape all characters in LaTeX to avoid breaking the output. To circumvent this, we created a type called LatexCell. If you wrap a value using this structure, then it will not be escaped. Thus, you must ensure you are using valid LaTeX commands. In this case, we can accomplish the same thing we had by:

julia> data = rand(3, 3);

julia> header = LatexCell.([latexify("α"), latexify("β"), latexify("ω")]);

\begin{tabular}{rrr}
\hline
\textbf{$\alpha$} & \textbf{$\beta$} & \textbf{$\omega$} \\\hline
0.379836 & 0.913338 & 0.271825 \\
0.104393 & 0.598591 & 0.113788 \\
0.943368 & 0.207498 & 0.0595488 \\\hline
\end{tabular}
2 Likes

I am curious why you didn’t use LaTeXStrings for this though. That way it would compose a little bit better with other packages.

I decided to go with that approach for cases that you have an object that when renders it outputs a LaTeX string.

I don’t understand. In many packages, LaTeXString fills exactly the function your LaTeXCell does.

Yes, but it will require to add LaTeXString as dependency. I try to keep the number of dependencies as minimum as possible to reduce loading time. In this case, the current approach will work with LaTeXString, Latexify, etc.

I can understand that, but LaTeXStrings has zero dependencies and 0.7ms loading time on my machine. While anyone wanting to output LatexCells in order communicate to PrettyTables that the output is a valid latex string has to depend on PrettyTables now, which has 130ms loading time.

PrettyTables is a low-level package to print tables. It does not make sense to output LatexCell if you are not using PrettyTables to print. No package should do this. When the time to print the data arrives, the function responsible for calling pretty_table can wrap the data in LatexCell.

I really want to keep the dependencies as low as possible. Now we have LaTeXString, but in the HTML backend, we might have the same problem and need to require another package. This can escalate quickly.

What can be implemented is a keyword allow_latex_in_cells (we have a similar one in HTML) that, if true, will not escape any cell. However, the user must be sure that all cells contain valid LaTeX code. What do you think?

1 Like