📈 Lilaq gets 0.1.0 years old − Plotting and scientific data visualization

[Mc-Zen]

Today is official π-day and also Einstein’s Birthday! What a perfect occasion to release a scientific data plotting framework. (And no, it wasn’t planned this way!)

Many of you have heard of this project through the talk at the recent Typst meetup. Now, we are excited to announce that the package is finally available.

Lilaq is a data visualization package for Typst, combining the:

• Ease of use and fast learning curve of Matplotlib, making it accessible for beginners.

• Possibilities of document integration and uniform styling of PGFplots, ensuring professional and consistent visual output.

It is easy to learn, features powerful configuration and preset creation through mock-up custom elements, and benefits from the real-time preview of Typst. Due to its use of the package Zero, consistent number formatting with the rest of the document can be guaranteed.

If you like Lilaq, you can support this immense endeavor with:

• a star for the repository, or

• a sponsorship on GitHub

Lilaq has a website! The entire documentation, filled with tutorials, examples, and detailed technical references, lives at:

• https://lilaq.org

Below you can find a simple usage example.

#import "@preview/lilaq:0.1.0" as lq

#let xs = (0, 1, 2, 3, 4)

#lq.diagram(
  title: [Data],
  xlabel: $x$, 
  ylabel: $y$,

  lq.plot(xs, (5, 4, 2, 1, 2), mark: "s", label: [A]),
  lq.plot(xs, (2, 5, 4, 2, 3), mark: "o", label: [B])
)

[Ants_Aare_Alamaa]

Been waiting for this to come out since you gave the talk! really good to see it finally be released!

[Gaweringo]

First of all, Very nice!

Second, Is there a plan to accept something like auto or 100% as the width and height for a diagram to make it grow to the available width / height?

[Mc-Zen]

Hi @Gaweringo ,
Yes, I’m working on that, at least for width!

It is actually very tricky to implement because the axes and other things occupy a certain width that is (almost) fixed while the diagram should occupy the remaining space. However, the amount of space that the axes need also depends on their length (because the automatic ticks might change), so it’s a bit of a recursive problem.

I have a few ideas how to tackle this but there are many things to consider.

[Mc-Zen]

By the way, the forum now has a lilaq tag:

Topics tagged lilaq,

which I have subscribed, so I’ll get notified when a question with this tag gets posted.

[adriano]

Finally what seems like an excellent plotting library for Typst, nice!

Although, as a long time ggplot fanboy, to be fair I cry a little bit at the matplotlib-like syntax, which I think is a scourge upon plotting libraries everywhere in the great wide world.

Nevertheless I understand the choice and I am sincerely thankful for the effort that seems to be put into this package - I can’t wait to start trying it out!

[Mc-Zen]

Thank you!

To be honest, I have never used ggplot. But I will take a look and check what I can learn from it.

Actually, the syntax is not that close to Matplotlib, for example almost all configuration goes through a more typsty way. Also I didn’t like the amount of use of abbreviated words…

Although the major design of Lilaq probably won’t change, I’m open to feedback and will gladly listen to ideas to make things more intuitive!

[Ants_Aare_Alamaa]

glad more people are actually making packages that use useful names.

“There’s two difficult problems in IT naming things and cache invalidation” - some guy

I hate how so many academic softwares use almost exclusively abbreviations, and even when there’s full names they tend to shorten it (try finding someone that doesn’t rename numpy as np). It really gives no benefit and makes it harder for other people who read it for the first time. Also if you really need it you can just define your own shortened functions and forward them to the properly named ones.

[adriano]

Ggplot has a completely different philosophy - one in which you declaratively stack aesthetics and rules on top of each other. Overall it is incredibly powerful while keeping fairly simple and readable - at least compared with MatplotLib.

A decent comparison here.

I think it’s way too different from the current approach you have taken so far, but maybe you can find some inspiration.

[janekfleper]

If you compare a built-in function from ggplot2 to a function that you have to recreate with the base functions in matplotlib (or even numpy and scipy), you are obviously going to get a difference in the readability. You are however comparing the different levels of abstraction, not the different philosophies.

[Mc-Zen]

Thank you @adriano , I will see what I can draw from it (edit: no pun intended ^^).

[Mr.Selfridge]

Looks awesome! So, what are the benefits of lilaq compared to cetz-plot (and vice versa) as they seem to partially cover the same use cases.

[Mc-Zen]

Hi @Mr.Selfridge ,

Thank you!

This is a good question and I’ll try to answer it as fair as possible. I have never actually used cetz-plot for a document because the first development of Lilaq dates back to around when also CeTZ-Plot started and I have always used my own project for any plotting I had to do.

I had kept the development private because my vision was centered around the power of Typst element functions with show and set rules but custom element functions were not − and are still not − available (see the talk from the Typst meetup that I linked at the top). So I worked around these limitations, avoiding to add options that were better suited to be exposed to the user through set or show rules.

Recently, a very interesting package was published: elembic (big shoutout and thank-you to @PgBiel). It simulates user-defined element functions in an experimental way and made publication of Lilaq possible. Now I was able to close these gaps of things that were not configurable before (like font size of tick labels or the length of ticks to just name two).

That being said, yes, the use cases of cetz-plot and Lilaq overlap largely. However, they differ greatly in design and how to use them.

I would say the power of Lilaq − and one of the main differences − lies in its very typst-y approach: it embraces the structure of the Typst language instead of imprinting an API design stemming from a different language upon it.

• almost everything, lq.diagram, lq.tick, lq.label, lq.title, lq.legend and many more are elements, meaning that you can:

  • Apply set rules to them to set a default value.
  • And apply show-set rules to manipulate their content.

  This drastically reduces the package API a user needs to learn. All kinds of options (e.g., text settings) that are usually needed for a visualization framework are dropped and replaced with things like show ...: set text().

• This directly implies another advantage: Once elements (or rather types) will be available, all option arguments to things like lq.diagram can be suggested by the IDE. This is valuable to check which options exist and how they are named without switching to the documentation all the time. In comparison, with cetz-plot, most styling options hide behind style dictionary parameters. For these, it will be hard for an IDE to provide information.

• A Lilaq lq.diagram takes the individual plots and other things as positional arguments (similar to the built-in table) while CeTZ expects a code block within which each CeTZcall returns an array (and these are auto-joined and collected by the surrounding canvas). This has advantages (e.g., there can be let statements inside the code without the need for a new scope) and downsides (error diagnostics when the user does something unexpected).

Also:

• Lilaq provides good defaults. I think it is very easy to start a new diagram with Lilaq. For example:
  • There is no boilerplate code and less braces/parentheses.
  • The tick generation algorithm is quite “smart” and usually gives good results out-of-the-box. I rarely find myself resorting to the tick-distance parameter.

Another point of comparison is the “syntax”, i.e., the API.

• CeTZ-Plot is close to PGFplots/tikz.
• Lilaq is closer to Matplotlib.

Some features that I can spontaneously think of that Lilaq has and Cetz-plot doesn’t have (afaik):

• Axis exponents or offsets (like ×10³).
• Customizable style cycles. Cetz-plot must have some cycle but there is no documentation on customizing it.
• Configurable numbers on the axes. Lilaq uses the package Zero. In cetz-plot you have to write a number formatter to change a detail (like the decimal separator or showing + signs for positive numbers).
• Scatter, colormesh, stem, and quiver plots.
• symlog and user-defined scales as well as secondary (or more) axes.

On the other hand:

• CeTZ-Plot also supports a few other things like pie and pyramid charts. I’m not saying that Lilaq will never have those but there are no immediate plans in that direction.
• CeTZ-Plot is part of CeTZ! You can easily embed a chart into a larger drawing and draw inside and all over the plot. Although Lilaq supports annotating and drawing within plots, it is rather primitive and you cannot really draw outside the diagram bounds.

Maybe it would be possible to work together with cetz on integration between the two (e.g., the ability to add CeTZ anchors to a Lilaq diagram).

I hope I could give an overview. If you have questions, feel free to ask.

[Mr.Selfridge]

Thanks for the more detailed answer than I was ever hoping to get! I’ll definitely explore how Lilaq works and look forward how possible Typst custom types will make it even more expressive.

Nice that there are options for different plotting needs!