Hacker News new | ask | show | jobs
by aragilar 616 days ago
The two baseline criteria I have for better-than-LaTeX options are:

1. Maths support equal to or better than amsmath 2. LaTeX-style macros

Both are needed to make writing large amounts of complex equations acceptable.

There should also be something similar to unicode-math, cleveref and biblatex, easy-to-use options to control layout/style/output (including metadata).

1 comments

I wrote a recent paper in typst. We ended up converting it to latex at the last minute to work with the conference’s submission guidelines, and work around a small bug (now fixed) in typst. But I would 100% use typst again. I wish it output html so I could use it for blogs & documentation.

The maths support was more than good enough for what we needed, and I enjoyed writing it a lot more than latex maths. The macro-equivalent support in typst is fantastic. It’s a standout feature. It has a full, modern-feeling programming language built in, complete with modules, functions, variables, arrays, the whole works. And there’s a growing ecosystem of 3rd party packages you can use with typst. Our benchmark scripts output the results into json files. Then when the typst document compiled, our typst source pulled in the benchmarking data directly from those json files. Then it used that data to populate tables and render charts directly, straight into the pdf. It was a lovely way to work.

(Though that said, I ended up swapping to a more fully featured external charting library because the charts it created looked better).

LaTeX maths or amsmath maths? TeX maths != LaTeX maths != amsmaths maths, and usually what I see described as "LaTeX maths" is TeX maths (or a subset, when someone claiming "LaTeX support" but not actually using LaTeX).

I'm not interested in a programming language (though naturally being able to write plugins would be useful ala luatex), but a textual macro system. I have things like (which is one of the simpler macros):

    \newcommand{\dt}[1]{\frac{∂#1}{∂t}}
so I can write things quickly and efficiently. That is the power of (La)TeX, and most examples I've seen of LaTeX alternatives seem to miss that use case, and instead focus on other things (e.g. HTML generation, alternate programming languages).
I'm not a latex expert. I don't know what the difference is between tex math, latex math and amsmath is. (And please don't explain it, I don't care.) Maybe there are some weird expressions out there that don't have a typst equivalent, if we really looked for them. But I haven't run into anything myself, despite writing a pretty math-heavy CS paper. (Or at least, the early drafts were math heavy.)

> I'm not interested in a programming language (though naturally being able to write plugins would be useful ala luatex), but a textual macro system.

Are you sure? Because latex macros like that are really horrible to read & write, and latex gives you notoriously hard to read error messages for your trouble. Here's the equivalent in typst:

    #let dt(x) = $(∂#x) / (∂t)$
In my opinion, this is way more readable. That code defines a lambda function (like arrow functions in javascript) that returns a "math mode" block ($this is a math block$). #x escapes the math block to evaluate x - which is just the function parameter we defined earlier.

And you'd use it simply:

    The result is $dt(y)$
Its not a macro system. Its just a function that you can call anywhere - including from other functions. And the function returns a block. I personally think its much nicer, and more familiar than the latex macro equivalent.
I'm curious, how does typst work out that I want the function expanded or I want the literal string if there's no marker.
There are 3 syntactic modes in typst: markup, code and math. In markup, everything is literal, unless you put a `#` sigil like `#expr` in which case `expr` is parsed in code mode. In code mode everything is an identifier, as usual in programming. In math its a bit of an ugly tradeoff but its ok: single-letter things are parsed as literals but multi-letter tokens are parsed as identifiers. Finally, in code you can enclose in `[...]` to parse in markup mode. So typically, your document will be mostly in markup mode and you will encounter stuff like `#something[An argument]`, which is a function call to which you pass one content-typed argument.

So above, `y` is parsed as literal, while `dt` is parsed as an identifier, hence function call.

> In markup, everything is literal, unless you put a `#` sigil

Unless it's a "=", then it begins a new section. And unless it's a "-" or a "+" or a "/", then it's a list item. And unless it's a "<", then it defines a label, or a "@", then it's a reference to one. And unless it's a "_" or "*" or "`", then it changes font or style.

I think I would have preferred a consistent sigil, but I guess with fast enough feedback you'd get used to the quirks.

I do wonder if this has over-optimised on short equations—to me heavy maths use implies multi-page equations with very specific formatting requirements (something amsmath has no issues with, which isn't surprising given who the authors are).