It turns out it’s easy to “leak data” from Typst by raising an error on purpose and parsing the error message. With that, it’s trivial to get the dimensions of text nodes (or anything else you need)
tmbb
tmbb
In case someone wants to be able to query element dimensions from Typst, I’m doing something like this:
defmodule Playfair.Typst.Measuring do
alias Playfair.Typst.TypstAst
alias Playfair.Typst.Serializer
alias Playfair.Length
def measure(elements) do
items = Enum.map(elements, fn element -> {element.id, element} end)
dictionary = TypstAst.dictionary(items)
serialized_dictionary = Serializer.serialize(dictionary)
# Insert the serialized plot into a template
typst_file = """
#let elements = #{serialized_dictionary}
#style(styles => {
let sizes = ();
for (id, element) in elements {
let size = measure(element, styles)
let line = (
id,
":",
repr(size.width),
":",
repr(size.height)
).join()
sizes.push(line)
}
assert(0 == 1, message: sizes.join("\\n"))
[Unreachable]
})
"""
# Try to render the typst code into PDF
# Typst will return an error
{:error, output} = ExTypst.render_to_pdf(typst_file)
[_ignore, data] = String.split(output, "assertion failed: ")
sizes =
data
|> String.split("\n")
|> Enum.map(fn line ->
[id, width, height] = String.split(line, ":")
{id, {parse_length(width), parse_length(height)}}
end)
|> Enum.into(%{})
Enum.map(elements, fn element ->
{width, height} = Map.fetch!(sizes, element.id)
%{element | width: width, height: height}
end)
end
defp parse_length(text) do
{float, ""} =
text
|> String.trim("pt")
|> Float.parse()
Length.pt(float)
end
end
0
tmbb
New version: GitHub - tmbb/quartz: Plotting for Elixir using Typst · GitHub
I’ve scraped pretty much the entire project and started over. The project is now called Quartz becuase it’s similar to the vaporware (?) Basalt python library described here. I thought that quartz is a nice name because it haZ all da Qool LetterZ and also because I initially tried to make it plotting-agnostic and something one could use just to draw figures. It turns out that supporting non-trivial plots actually required the whole thing to be plot-oriented, but now it’s too inconvenient to change the name.
The basic idea is that Quartz converts your instructions on how to draw a plot into linear progamming constraints, which it then solves using my Dantzig library (very unstable, and only supports Linux at the moment). Dantzig uses an open source linear programming solver which is bundled as a binary in the source.
Unfortunately, once part of your program is based on constraint solving, then all your program must be based on constraint solving, which means that there is no compatibility between Quartz and Playfair. I believe that constraint solving is probably more extensible and even composable, but it’s definitely a bit harder to implement than the naïve version.
One of the good parts is that although I still use typst as a rendering engine, I now perform all layout calculations in Elixir based on the text dimensions returned by Typst (determining text layout is impossible in Elixir, but actually very easy in Typst). You’re not meant to be able to query typst for object dimensions, but it’s very easy to do by intentionally raising an exception inside typst and then parse the error logs. The fact that just before generating the typst code you have access to all object dimensions might be useful in the futuren for some “post processing” just before sending the output to typst.
Because it was so hard to reimplement everything in constraint solving, I can’t actually show a full plot yet, but I can show the outside decoratios of a plot (the actual data would go into the central square delimited by the solid lines. The dotted lines are the boundaries of the canvases into which Quartz divides the image.
A very preliminary example of two plots side by side, with proportions specificed by the user:
The source code thath generates the figure above:
def example() do
use Dantzig.Polynomial.Operators
alias Quartz.Figure
alias Quartz.Plot2D
alias Quartz.Length
figure =
Figure.new([width: Length.cm(16), height: Length.cm(6)], fn fig ->
figure_width = fig.width
_plot_task_A =
Plot2D.new(id: "plot_task_A", left: 0.0, right: 0.55 * figure_width)
# Use typst to explicitly style the title and labels ――――――――――――――――――――――――――――――――
|> Plot2D.put_title("A. Task A")
|> Plot2D.put_axis_label("y", "Y-label")
|> Plot2D.put_axis_label("x2", "X2-label")
|> Plot2D.put_axis_label("x", "X-label without $math$")
|> Plot2D.finalize()
_plot_task_B =
Plot2D.new(id: "plot_task_B", left: 0.55 * figure_width + Length.pt(8), right: figure_width)
# Use typst to explicitly style the title and labels ――――――――――――――――――――――――――――――――
|> Plot2D.put_title("B. Task B")
|> Plot2D.put_axis_label("y", "Y-label")
|> Plot2D.put_axis_label("x2", "X2-label")
|> Plot2D.put_axis_label("x", "X-label (with math: $x^2 + y^2$)", text: [escape: false])
|> Plot2D.finalize()
end)
Figure.render_to_pdf!(figure, "example.pdf")
end
Unlike Playfair, in which almost everything is pure and referentially transparent, with very little use of the process dictionary, Quartz is an imperative monster which invisibly builds a linear program behind your back inside the process dictionary. It does try to hide this fact very well. As a user, you never need to know that anything is happening inside the process dictionary. It does make it very hard to generate plots in parallel, though (but it’s definitely something I could address in the future).
Plans for the future
The fact that Quartz has access to a linear programming solver means I can have more advanced layouts almost for free, and it makes it very easy to deal with variables whose value is substitued later (it’s basically lazy evaluation implemented on top of a linear programming solver). The main problem is that Quartz may raise an error if you tell it to draw something impossible. Supposedly, this can only be triggered by the user if the user tries to draw a figure which is too small for the fixed-size elements it contains.
0
tmbb
For those who might be interested, Quartz now supports multiple axes per location (bottom, top, right or left). It just draws the axes (which are simply a line with a label, I can’t yet add any data or even axis ticks). You can see an example with some “cursed” units.
The code that generates that plot is very similar to the code above, it just adds some extra drawings to the plot:
figure =
Figure.new([width: Length.cm(16), height: Length.cm(6), debug: false], fn fig ->
figure_width = fig.width
_plot_task_A =
Plot2D.new(id: "plot_task_A", left: 0.0, right: 0.55 * figure_width)
|> Plot2D.add_bottom_axis("x3")
|> Plot2D.add_bottom_axis("x4")
# Use typst to explicitly style the title and labels ――――――――――――――――――――――――――――――――
|> Plot2D.put_title("A. Task A")
|> Plot2D.put_axis_label("y", "Y-label")
|> Plot2D.put_axis_label("x", "X.A axis label (mg/m#super([-2]))", text: [escape: false])
|> Plot2D.put_axis_label("x3", "X.B axis label (Kg$dot$s#super([-2/3]))", text: [escape: false])
|> Plot2D.put_axis_label("x4", "X.C axis label (mmol$dot$kg#super([-5/7]))", text: [escape: false])
|> Plot2D.put_axis_label("x2", "X2-label")
|> Plot2D.finalize()
_plot_task_B =
Plot2D.new(id: "plot_task_B", left: 0.55 * figure_width + Length.pt(8), right: figure_width)
# Use typst to explicitly style the title and labels ――――――――――――――――――――――――――――――――
|> Plot2D.put_title("B. Task B")
|> Plot2D.put_axis_label("y", "Y-label")
|> Plot2D.put_axis_label("y2", "Y2-label")
|> Plot2D.put_axis_label("x2", "X2-label")
|> Plot2D.put_axis_label("x", "X-label (with math: $x^2 + y^2$)", text: [escape: false])
|> Plot2D.finalize()
end)
path = Path.join([__DIR__, "side_by_side_plots", "example.pdf"])
Figure.render_to_pdf_file!(figure, path)
Again, I’m very happy with this because the main challenge in data visualization libraries is often not displaying the data (which is just a set of simple shapes put in the correct position) but also the “boring” parts such as axis labels, plot titles and all those things which are essential in order to have a publisheable plot.
The labels for the vertical axes should be rotated, but I don’t support rotated text yet
1
tmbb
Ok, some reality check: the the approach I took is mathematically very elegant. Pretty much every measurement in the figure is represented by a (sometimes) multivariate polynomial, which is implemented symbolically with what I think is a pretty clever canonical representation.
Each polynomial is a struct containing a map from products of variables to coefficients. For example, ab + 7cd + 9 is represented by %{["a", "b"] => 1, ["c","d"] => 7, [] => 9}. I then implemented symbolic operations such as addition, multiplication and variable substitution on top of this representation. While building the figure, I generate constraints between degree one polynomials and feed them into the linear solver in order to get numerical values. Then, I substitute the variable values in the polynomials and turn all dimensions into nice floating point numbers.
One of the best parts of this is that I can get the text dimensions all at once from Typst, instead of querying it every time I want to render a text element.
All of this (predictably) takes a huge amount of memory when drawing lots of objects if the and size of every element is kept as as an independent polynomial. Maybe I should create some new object types like point clouds which store the dimensions of the full cloud as polynomials and the and the dimensions of the points as floating points between 0 and 1 relator to the dimensions of the cloud.
The basic design is quite robust and can handle these optimisations. The only problem is that because I don’t have much control over the constraint solving process, some figures might be impossible to draw and raise an error, especially if the figure size is too small. Maybe I should tag the constraints with different levels of priority and relax them if the first attempt fails.
1
tmbb
Quartz (this library is no longer called playfair) can now draw line plots (by very inefficiently drawing line segments individually instead of using a normal path because I haven’t iomplemented paths yet).
Example here:
Code:
defmodule Quartz.Benchmarks.LinePlot do
use Dantzig.Polynomial.Operators
require Quartz.Figure, as: Figure
alias Quartz.Plot2D
alias Quartz.Length
def build_plot() do
figure =
Figure.new([width: Length.cm(8), height: Length.cm(6), debug: false], fn _fig ->
[[bounds]] =
Figure.bounds_for_plots_in_grid(
nr_of_rows: 1,
nr_of_columns: 1,
padding: Length.pt(16)
)
x = for i <- 1..100, do: 0.01 * i
y = for x_i <- x, do: x_i * 0.3 + (0.05 * :rand.uniform())
data = %{x: x, y: y}
_plot =
Plot2D.new(id: "plot_A")
|> Plot2D.set_bounds(bounds)
|> Plot2D.line_plot("x", "y", data)
# Use typst to explicitly style the title and labels ――――――――――――――――――――――――――――――――
|> Plot2D.put_title("A. Line plot")
|> Plot2D.put_axis_label("y", "Prediction: $f(x)$", text: [escape: false])
|> Plot2D.put_axis_label("x", "Predictor: $x$", text: [escape: false])
|> Plot2D.finalize()
end)
path = Path.join([__DIR__, "line_plot", "example.pdf"])
Figure.render_to_pdf_file!(figure, path)
end
end
3
tmbb
I have changes the API by making axes implicit (usually one wants to plot on the x and y axis, and specifying that everytime gets boring).
I show an example (which actually contains no new functionality) of plotting the KDE of the posterior probability distribution for a parameter in a simple Bayesian model. The model was fit using Stan, with bibndings provided by my Ulam package. Below, I show the code, which is quite involved, because I build the KDE “outside” of quartz. I will move this functionality inside Quartz so that one can simply write Plot2D.plot_kde(series) and quartz will handle the details (usually there isn’t much you want to do with a KDE except plotting it or using linear interpolation to learn a couple things about it). This plot showcases the use of line plots (line plots become quite smooth if you choose fine subdivisions) and the use of color to distinguish between the montecarlo chains.
This visualization is inspired by what you get with the python library ArViz, which provides much more functionality. However, once you get deep into ArViz you start to notice that a lot of what you have to deal with is to “undo” all the clever things that ArViz does in order to organize your data the way it thinks is best. The structure I build, which is simply a “raw” dataframe containing the Stan output is also quite functional for what one usually wants to do.
Finally, the code:
def visualize() do
samples = DataFrame.from_parquet!("examples/bernoulli_model/samples.parquet")
figure_attributes = [
width: Length.cm(8),
height: Length.cm(6)
]
colors = [
RGB.hot_pink(0.4),
RGB.dark_violet(0.4),
RGB.medium_blue(0.4),
RGB.dark_red(0.4)
]
figure =
Figure.new(figure_attributes, fn _fig ->
theta_kdes =
for chain_id <- 1..4 do
theta = DataFrame.filter(samples, chain_id__ == ^chain_id)["theta"]
Sandbox.kde(theta, 200)
end
plot =
Plot2D.new(id: "plot_A")
|> Plot2D.put_title("A. Posterior probability for $theta$ (all 4 chains)", text: [escape: false])
|> Plot2D.put_axis_label("x", "$theta$", text: [escape: false])
|> Plot2D.put_axis_minimum_margins("x", Length.pt(10))
|> Plot2D.put_axis_minimum_margins("y", Length.pt(10))
plot =
Enum.zip(theta_kdes, colors)
|> Enum.reduce(plot, fn {theta_kde, color}, plot ->
x = Series.to_enum(theta_kde["x"])
y = Series.to_enum(theta_kde["y"])
Plot2D.line_plot(plot, x, y, style: [color: color])
end)
Plot2D.finalize(plot)
end)
path = Path.join([__DIR__, "bernoulli_model", "theta.pdf"])
Figure.render_to_pdf_file!(figure, path)
end
0
tmbb
So, Quartz is not dead yet! I have added functionality to plot KDEs. So Quartz can now do scatter plots, line plots and KDE plots. The newer version of Quartz can’t do boxlplots or bar plots yet, but they’ll come eventually.
The code to generate the figure above now looks like the following:
defmodule Quartz.Benchmarks.LinePlot do
use Dantzig.Polynomial.Operators
require Quartz.Figure, as: Figure
require Explorer.DataFrame, as: DataFrame
alias Quartz.Plot2D
alias Quartz.Length
alias Quartz.Color.RGB
def build_plot() do
data_path = Path.join([__DIR__, "data", "samples.parquet"])
samples = DataFrame.from_parquet!(data_path)
theta_1 = DataFrame.filter(samples, chain_id__ == 1)["theta"]
theta_2 = DataFrame.filter(samples, chain_id__ == 2)["theta"]
theta_3 = DataFrame.filter(samples, chain_id__ == 3)["theta"]
theta_4 = DataFrame.filter(samples, chain_id__ == 4)["theta"]
color_1 = RGB.hot_pink(0.4)
color_2 = RGB.dark_violet(0.4)
color_3 = RGB.medium_blue(0.4)
color_4 = RGB.dark_red(0.4)
figure =
Figure.new([width: Length.cm(8), height: Length.cm(6)], fn _fig ->
_plot =
Plot2D.new(id: "plot_A")
|> Plot2D.kde_plot(theta_1, style: [color: color_1])
|> Plot2D.kde_plot(theta_2, style: [color: color_2])
|> Plot2D.kde_plot(theta_3, style: [color: color_3])
|> Plot2D.kde_plot(theta_4, style: [color: color_4])
# Add some margins to the plot
|> Plot2D.put_axes_margins(Length.cm(0.25))
# Use typst to explicitly style the title and labels
|> Plot2D.put_title("A. Probability distribution")
|> Plot2D.put_axis_label("x", "$theta$", text: [escape: false])
|> Plot2D.put_axis_label("y", "$P(theta)$", text: [escape: false])
|> Plot2D.finalize()
end)
path = Path.join([__DIR__, "dist_plot", "example.pdf"])
Figure.render_to_pdf_file!(figure, path)
end
end
Not how tha KDE is automatically computed from the observations.
A natural next step would be to support lazy color maps. Lazy color maps are a bit hard, because they can’t return a color until the plot is finalized. I have to accumulate constraints and resolve them only after I decide I don’t want to draw anything else in the plot. I can’t determine the color of each line before drawing all the lines…
I do have a naming question, though: plot can be both a name and a verb. When I call Plot2D.kde_plot/1, I want to add a KDE plot to a plot. The name doesn’t feel natural. Renaming it to plot_kde would be more natural, but then it would not be consistente with scatter_plot… I can’t change it to plot_scatter because it makes no sense. Since we are adding plots to a plot (?), maybe I should rename it to Plot2D.add_kde_plot or Plot2D.draw_kde_plot, which would allow for consistent naming for all the plots: draw_kde_plot, draw_scatter_plot, draw_line_plot, etc. What do people here think?
Regarding performance, it’s still horrible for plots that have ~1000 elements. The main bottleneck is keeping all the dynamic constraints and then replace all variables by their values. This takes a lot of time and a lot of memory too.
0
tmbb
I think I’ve finally hit Quartz’s performance limitations, namely the memory consumption. I’m trying to generate contour plots, which for a large number of contours result in a large number of line segments, and even for modest sized grids and for modest numbers of contour levels, quartz segfaults. The problem seems to be in the more “algebra-heavy” elixir code, such as the functions that substitute the variables in the polynomials by their values after solving the linear programming.
An example of a contour plot (with 4 levels) and an 15x15 grid:
0
tmbb
For anyone following this, it turns out I’m a total idiot… Elixir is handling tens of thousands of elements just fine, as I have just discovered with better benchmarking. Even if each element contains a number of totally not optimised polynomials implemented as structs.
It turns out that unlike what I previously reported, the problem is with typst. Problems start to happen when I try to compile typst files of > 20.000 lines with a large number of graphical objects. To be fair to typst, these files are probably much larger than anything anyone has tried to use typst on (I don’t know whether the critical part is the patching or the rendering, but I’m not that interested in finding out).
Because of this, I have decided to keep the core constraint-based architecture the same and drop typst. I’ll be try to use resvg (the rust svg rendering library, which also has Elixir bindings) for text rendering and measuring and to render SVGs into PNGs. I assume that resvg is probably better optimised than typst for rendering larger numbers of shapes.
The only thing I lose is math typesetting, but it turns out plots don’t use that much math typesetting. One can get by with unicode symbols, superscripts, subscripts and not much else.
5