Hi! I recently discovered Typst after decades as a LaTeX user, and I really like the syntax, as well as the general design and the scripting system.
However, I am slightly skeptical about using thin inside equations for spacing. I tend to use it a lot to achieve pleasant spacing, like this
$
integral x f(x)/2 dif x \ // too tight between x and f(x)
integral x thin f(x)/2 dif x // just right
// integral x\,f(x)/2 dif x // latex-inspired syntax
$
Is there any way to make a more inobtrusive code for thin-space? I fear that my equations will look messy with all the visually âheavyâ thins. I could perhaps make an alias ts for thin, but ideally, it would be something that looks like punctuation, as in LaTeX. (I actually tried directly inserting a unicode thinspace, but that had no effect.)
Edit: Split off second question to its own thread.
BTW, and this goes a bit more into the typography of equations:
Observe the output of this code
$
a dot b , a dif x , a times dif x , a f(x)/2 x , a thin f(x)/2 thin x
$
As can be seen, many operators put a nice bit of extra space around them. dot and times put space on both sides, dif puts space between itself and the preceding character (but this apparently collapses after an operator with spacing â nice!). But the large fraction puts no extra space around it, and I consistently need to add it with thin (or \, in LaTeX).
Should there be extra space around fractions? I think so, but at least if the fraction is several characters wide. Can I tweak Typst to add this by default? That would drastically cut down on my use of thin.
for this specific case you can do a show rule on math.frac. Iâm not an expert on math typesetting, so this might have some rough edges, maybe someone else can judge that:
$
a thin f(x)/2 thin f(x)/2 thin x
$
#show math.frac: it => {
let thin = h(math.thin.amount, weak: true)
thin + it + thin
}
$
a f(x)/2 f(x)/2 x
$
Note that I donât use thin directly so that I can make it weak; this avoids doubling the space when there are two fractions in a row.
Could I ask you for some things though? You question would better fit the, well, Questions category. (EDIT: I moved it there because I think you probably donât have the permission to move your topic yourself.) In that category, topics should best have a full question as a title, as per the question guidelines :
Good titles are questions you would ask your friend about Typst.
Also, since youâre basically asking two separate questions (math typesetting and the editor experience of doing Unicode input) it might later not be easy to find both answers in this thread â which would be a shame because I find both questions very interesting. Could you split off the second question into a separate topic, with its own fitting title? That would be very helpful
This is great and definitely helps! I really enjoy the show-rule design in Typst.
But do you happen to also know if I can define a âlighterâ way to explicitly insert thin spaces? Hopefully, I wonât need them that often when I have the option to create such rules.
Thanks for the feedback. I tried to do as you suggested.
Why does this happen, though? It looks like the show rule should only modify the spacing around frac. Why would it bleed into spaces after the next character?
One thing I donât get is: why is there appropriate spacing around most operators, but not around fractions? This is the same for LaTeX, BTW.
I believe it happens because there is no longer a non space character before the +, and so it is treated as a unary operator instead of a binary one. This causes the spacing to change. This is controlled by math.class. + has the class "vary", which is the reason the behaviour described above occurs.
Currently though, math.class is only intended to modify symbols (i.e. single characters). If you try setting the class on math.frac in a show rule, it applies to every character within the fractionâs content. The reason for this behaviour is that the class of a character comes from Unicode (see UTR #25 Math-Class Property for example, though this may be outdated), and thus I figure (?) its intended to only be a property of a single character.
Maybe math.class could be changed to work on arbitrary content in the âexpectedâ way. Though I donât know if there would be any unintended consequences.
I donât think so, show rules for text donât seem to be the right tool here (and I think they donât work well in math anyway) and Typstâs variables canât be punktuation.
I think this would be worth opening an issue on Github over. It sounds like there could simply be a better default, a setting on frac, and/or the behavior of class could be more generalized. Basically, it not being pretty out of the box is a bug.
Iâm not so sure if there should be any space around frac by default.
There is also no space between variables $x y z$ or between normal numbers and variables $5 x$ so why should there be a space between a fraction and a variable $4/3 x$. Fractions should be treated just like numbers.
In case of the original example $a f(x)/2 x$, you would also not be surprised if there was no space between $a 5 x$. Just write $a dot f(x)/2 dot x$.
Or maybe here is a good idea: I can see why you would want spacing around fractions if the fraction is not a rational number like $4/3$ but for example the numerator contained an operator which usually has some spacing around it.
So how about the spacing of a fraction should just be taken as the spacing of the numerator of the fraction? If the numerator contains a number, no spacing. If the numerator contains an operator etc., then there is spacing.
My reasoning is that large âentitiesâ should have more space around them, so that is why I virtually always end up inserting extra adjustment space next to them. Whether there are operators in the fraction or not, it is more than twice as tall as x, and needs more space, according to my personal tastes.
Not everyone agrees, so I would be happy with a nice way of manually inserting space, but am slightly unhappy that this means typing in a visually heavy phrase like thin, which looks more prominent than the neighboring x. It is a purely cosmetic adjustment which carries no mathematical meaning, and I was hoping to be able to insert it with some more lightweight notation.