Math

[subtle elbow]

NewCM 8.0.0 is out!
https://download.gnu.org.ua/pub/releases/newcm/

It has been submitted to CTAN as well

[desert spire]

PR up https://github.com/typst/typst-assets/pull/18

[desert spire]

I've noticed that there is no double exclamation symbol in codex. More on the math side though, I think !! makes sense as a shorthand in math for ‼

[tawdry dock]

I don't understand why you would use such a restrictive license....

[tawdry dock]

I don't think it's a math symbol

[subtle elbow]

What does this symbol mean?

[desert spire]

I actually found out about it from the MathML operator dictionary, and its used on wikipedia instead of two !

[desert spire]

https://en.wikipedia.org/wiki/Double_factorial

[subtle elbow]

Why does Unicode have so many precomposed juxtapositions? 😭

Reminder that ⩶ is a single Unicode codepoint

[desert spire]

so it is presumably semantic and should be used as opposed to two !

[subtle elbow]

Okay that makes sense

[tawdry dock]

https://en.wikipedia.org/wiki/Double_factorial is a thing (not very widely used)

[tawdry dock]

The page I linked seems to use two !

[subtle elbow]

I think the shorthand would be fine.
In Codex, it would probably be excl.double

[desert spire]

I can't tell because the math is rendered (to svg?), but in the first line

In mathematics, the double factorial, or semifactorial, n‼

uses the right unicode char

[tawdry dock]

Okay I retract my claim. It is listed on the big list in unicode-math

[subtle elbow]

Actually, excl.double already exists

[desert spire]

i might open a PR adding it as a shorthand then, it seems very uncontroversial

[desert spire]

i'm guessing it is new? couldn't find it in the docs sym list I'm wrong it is there

[subtle elbow]

It's not new

[desert spire]

I just did a bad job

hmmm on further research it seems like it may not actually be used as a math symbol after all...

the mathml operator dictionary only has "!!" (the string literally) not the single unicode char

[tawdry dock]

It is included in several math fonts at least

[desert spire]

it seems quite a few don't have it though either? Looking at the unimath-symbols.pdf

[tawdry dock]

Yeah

But that's the case for many more obscure symbols

[desert spire]

True. Making it a shorthand though to convert to a single unicode char would make life much easier throughout the compiler, all the way through to MathML export (I'm only looking at this because n! is emitted as <mi>n</mi><mi>!</mi> currently, instead of the ! being a mo)

[tawdry dock]

Can the web app (or even typst itself) even use the font with that license?

[desert spire]

oh thats a good point

[tawdry dock]

<@&1200368100202258552> might want to check it out

He may not have thought through the consequences of such a license change

[desert spire]

He actually emailed me a while back asking about the change of the license (this was suggesting GPLv3+FE only then) and after asking Laurenz I responded saying it would be an issue for the compiler binary and to discuss with the team directly. AFAIK they never got a reply, but the new release included this "distribution exception", which I'd infer is the maintainer's way to ensure the fonts can be bundled into Typst

But yeah idk how that then applies to other projects using Typst that use a license "incompatible with the GPL"

[tawdry dock]

The distribution exception wouldn't help though, because it's not compatible with MIT

[desert spire]

It is with apache though (which is what the compiler is licensed under)

[tawdry dock]

https://www.apache.org/licenses/GPL-compatibility.html

However, GPLv3 software cannot be included in Apache projects

[desert spire]

But

This licensing incompatibility applies only when some Apache project software becomes a derivative work of some GPLv3 software, because then the Apache software would have to be distributed under GPLv3.

And the exception explicitly says though that any program distributing the fonts with a license compatible with GPL isn't considered a derivative work under GPL

[tawdry dock]

Okay but even if that's the case it still may be a problem for the web app no?

[desert spire]

it might be, yeah.

[oak salmon]

I think you're right, since the app runs locally in the user's browser it must count as distribution

(if it was like overleaf it would be different, you would need the affero gpl to trigger the restrictions)

[tawdry dock]

I don't see how client/server side is relevant here

The bigger issue would be that the web app is not open source

Anyway, I leave this for the Typst GmbH legal department :p

[oak salmon]

usually if you use GPL software in your cloud app, you are not restricted in any way, as long as you only give the output to the user because the restrictions only kick in when you distribute the software (the Affero GPL was developed to plug this hole). So if overleaf was closed source they could still use GPL software in the backend without problem. But since the whole Typst sofware is sent to the client when you load the app (including the part that uses the fonts), it probably counts as distribution so the GPL would kick in

[tawdry dock]

https://github.com/typst/typst/issues/1435 should this have been closed with https://github.com/typst/typst/pull/7742 ?

I don't know how to interpret laurenz' "We should probably avoid the "Closes X" syntax until things have actually landed in main."

oh it's because it's only the math-syntax branch

[fresh horizon]

Yeah, the goal is to close the relevant issues only when the branch merges to main, like how #7741 hasn't closed #4971 yet

[static vortex]

Martin and I have re-consulted the GPL text, checked the font's additional license text, and have concluded that New CM's terms are okay for both the open-source compiler and our web app.

[tawdry dock]

That's good

Better safe than sorry

(I still think it's an awkward license for a font)

[static vortex]

I agree and we would also avoid adding any other GPL-licensed fonts because there are always legal insecurities with GPL.

[tawdry dock]

It sounds like the maintainer of NCM had tried to contact you, but didn't get an answer? Maybe you could ask if he could change his mind

[static vortex]

No he didn't contact us

He contacted @desert spire, which referred him to us, but we never received an email.

[tawdry dock]

#1176478139757629563 message

AFAIK they never got a reply

[subtle elbow]

I think "they" is referring to the team here

[tawdry dock]

Hm, maybe I misunderstood then

[sleek magnet]

If that's the case, @desert spire could make an introduction, I'd be happy to sort this out

[tawdry dock]

https://ctan.org/pkg/newcomputermodern it's live on ctan now

All fonts are distributed under the GUST license except

NewCM10-Regular, all NewCMUncial, and all NewCM*Devanagari which are

So is the math font not GPL then?

[desert spire]

Not yet, I think he said the roman letters are from Latin Modern, which is under OFL which is incompatible with GPL. So he needs to retrace them from scratch

So far its just been done for NewCM10-Regular (and the other fonts under the new license don't have those roman letters)

[tawdry dock]

So why is he so interested in making it GPL exactly?

[desert spire]

Idk, he just wants to license his work under a more copyleft license I suppose

[tawdry dock]

that's not really the tradition for non-commercial fonts though

I guess I can understand where he's coming from, but I also think it can potentially cause people to stop using it because of potential headaches

[tawdry dock]

@desert spire is this still supposed to be open https://github.com/typst/typst/issues/3784 ?

[desert spire]

I suppose it has turned into a feature request now for some smarter alignment of underbrace text

Typst matches luatex exactly now

[desert spire]

I didn't want to close it because the 'issue' is still there, even once we've aligned with luatex

[tawdry dock]

Integral.slash has broken script placement in luciole, has anyone reported that?

I didn't check the other more specialized integral symbols, but I suspect they're similar

[tawdry dock]

I was under the impression that this should have variation selectors now @subtle elbow ?

[subtle elbow]

I am not sure what causes this result, as a font that does not support variation selectors should at worse display the original thing followed by an empty glyph (for the variation selector)

[tawdry dock]

Some regression on main?

[subtle elbow]

Although here the situation is a bit more complex because Typst is emitting variation sequences that are not valid Unicode. But the font shouldn't react in this way either way

[tawdry dock]

it works with capital letters

though they're the same

maybe the lower case ones are simply missing in lete sans math

Or am I misremembering whether the lowercase one even exist?

[subtle elbow]

Lowercase script letters have no standardized variation sequences in Unicode, but we emit the variation selector anyway. I was against that but we decided otherwise (can't find where though)

[tawdry dock]

That seemingly breaks some fonts

ah nm, it simply doesn't have the glyph in the first place

I'll see if I can find one that has the lowercase ones

[subtle elbow]

Oh that's right, I just checked as well

[tawdry dock]

It would be better if only one tofu was shown instead of two

at least

But I guess it doesn't really matter that much

Wait, Lete is supposed to have both cal and scr

https://github.com/abccsss/LeteSansMath/issues/20

that is a capital letter

[subtle elbow]

The version on the webapp must be outdated then

[tawdry dock]

https://github.com/typst/webapp-issues/issues/710 was closed

let me upload it manually

[subtle elbow]

When uploading it manually it works for me

[tawdry dock]

Okay, I added a comment to the issue

Since it's in the web app issues repo I can't reopen it

@upper trench do you have the power to do that?

[upper trench]

I'm afraid the issue was indeed solved internally , but i wonder if the wrong font version was used? Is there a way to check?

[tawdry dock]

You would need to check which font file is on the server I guess. I don't think there's a way to check the metadata from the web app

But it's definitely the wrong one

Maybe updated but not the latest one

[upper trench]

the latest is 0.61?

[tawdry dock]

Yeah

[upper trench]

weird

ill ask laurenz about it

well, tomorrow

[static vortex]

@tawdry dock The font is definitely updated and I also see the scr version. You probably have an outdated cached version in your browser. Try clearing the cache. This is one of the reasons why I dislike updating fonts (next to reproducibility) --- our current font caching is very aggressive because the fonts consume a lot of bandwidth and we do not yet have a good way to evict these caches.

[tawdry dock]

Sorry for the false alarm then! I will keep in mind the cache from now on.

I still think, on balance, keeping fonts updated is a good idea 🙂

I don't know how the caching works, but can a hash not be used to solve this issue?

Like, just including a hash in the file name

[static vortex]

Yes, that would be the solution. But we'd also need to have something in place that ensures font updates don't silently break tabs that haven't yet reloaded and still have the old font index (which would then try to fetch a deleted file). So either both fonts need to be retained or something else. It's not super hard, but there would be some engineering effort involved.

[upper trench]

One of the two hardest problems in programming after all 😂

[subtle elbow]

#show math.equation: rect.with(stroke: purple)
#show math.equation: set text(font: "New Computer Modern Sans Math")
$ floor(vec(n, n, n, n)) $

renders incorrectly. This is an issue with NewCM Sans Math, right? I just want to confirm before sending an e-mail.

[tawdry dock]

Does it only happen with the show rule?

[subtle elbow]

The rect show rule is to show the size of the equation and is not necessary

The font rule is necessary

[oak salmon]

there's probably something wrong with the font indeed... trying the following with texlive 2025 and lualatex on overleaf:

\documentclass{article}
\usepackage{amsmath}
\usepackage[sansdefault]{fontsetup}
\begin{document}
\[
    \left\lfloor \begin{pmatrix} n \\ n \\ n \\ n \end{pmatrix} \right\rfloor
\]
\end{document}

while when you remove the "sansdefault"

[tawdry dock]

Presumably something wrong with the font metrics, and tex handles it somewhat more gracefully

[oak salmon]

Currently math.class can be used on any content, but it's applied recursively. Should that be changed? It would allow doing something like the following:

?r

$
  &log x \
  &log (x+y) \
  &log class("normal", (x+y)) \
$

[oak salmon]

here class is used to have the whole (x + y) treated as normal (to have spacing with log consistent with the "log ..." notation), but it screws the spacing around + inside

(See forum thread for context)

[desert spire]

I recall coming across this before too. Applying it recursively probably isn't best, but I don't know whether not doing so will have any undesired side effects?

[tawdry dock]

I can't think of any situation where recursive would be desirable. But maybe I lack imagination

[desert spire]

i suppose the only issue would be that then it can't go on the style chain (at least not easily), since that applies recursively.

is there an issue open for this?

[tawdry dock]

Not that I know of

https://ctan.org/pkg/lua-unicode-math I discovered this, not sure how much faster it actually is than unicode-math, since no benchmarks are provided

[oak salmon]

I filed one here: https://github.com/typst/typst/issues/8239

[oak salmon]

maybe it could work similarly to how math.op works?

?r

$
  op(A.B) x \
  op(A) op(.) op(B) x
$

[desert spire]

Hmm I need to double check the code. It might actually just be super simple

[oak salmon]

Would be nice! I was a afraid it could be tricky, as I guess math.class should ideally apply only in relation to the outside, i.e. in the log class("normal", (x+y)) example it should set the class of ( in relation to the log, but not in relation to the x

[desert spire]

Yeah that's the bit that I can't quite remember

[subtle elbow]

With MathML export, I get the following error message in the Firefox console:

Balisage non valide : le nombre d’enfants de la balise <msubsup/> est incorrect.
Which translates to
Invalid tags: the number of children for the <msubsup/> tag is incorrect
Is this expected or should I try to find a minimal reproduction?

[sage breach]

probably MRE

esp before release very valuable

[tawdry dock]

What does the mathml in question look like?

[subtle elbow]

It's within a huge document. I don't know where in the HTML file the error comes from

[subtle elbow]

False alarm. The issue was likely due to a weird show rule

[tawdry dock]

I would still not expect weird show rules to cause html errors

Unless you're injecting raw invalid html

[desert spire]

You can write some very weird show rules, but even the invalid HTML errors you might cause are very benign

[tawdry dock]

Performance is no issue, ~8% faster than main on the math heavy test (test run 200, compared with 196). Not too shabby.

How does one get 8% from 196 and 200 @desert spire ? 😅

[fresh horizon]

Those are test run numbers, Laurenz has a computer for comparing performance that some contributors can access remotely and run branches on. Not really meant for public use, so I'm not gonna link it unless he does, but there is a publicly accessible site

[tawdry dock]

That's fine, I thought it means 196 and 200 runs of some document in a given amount of time, respectively

[desert spire]

Yeah I don't want to link the site as it isn't exactly for public use. The run numbers are there for Laurenz then to have a look when he reviews it

[tawdry dock]

Is there some other refactoring that makes it go faster? My understanding was that it's now doing more things?

[desert spire]

It is doing more things, but some careful modification of what gets memoized netted the speed up

I wasn't expecting it to be faster, I just didn't want it to be slower

[tawdry dock]

happy little accidents

[static vortex]

https://github.com/typst/typst/issues/8343 is technically not really upstream but if at all rather downstream, right? Maybe we should have separate labels for these two things?

[desert spire]

True, adding a separate label makes sense

[tawdry dock]

There's a new bug fix release of old standard math https://ctan.org/pkg/oldstandard

(date is wrong in the version field on ctan, it was released today)

..I wrote pennstander for some reason,

[sick lagoon]

Now that https://mathup.xyz came up again in #discussions, I was remembered that I liked it having special syntax for tensor indices (i.e. indices that are not merged but each have their own column). What do you think about adding something like this to Typst? Writing tensor indices is a bit of a pain right now. My best workaround is writingR^μ""_(ν ρ σ), but that is not really correct.

[tawdry dock]

I think this is a job for a package

https://ctan.org/pkg/tensor could be a source of inspiration

[subtle elbow]

I don't know whether the Math Refactor™ people have discussed this particular point, but I could see (R^μ)_(ν ρ σ) working for this purpose. Although this may have the drawback of making it more annoying to write sequences: ((u_i))_(i in NN)

[tawdry dock]

I think it'd be almost impossible to create a syntax that's flexible enough, unambiguous, not super ugly, and also amenable to the level of tagging required by pdf/ua-2

Mathup doesn't need to care about these things since it's very much limited in scope

[sick lagoon]

I suppose sequences are more common in general, so I don't know how I feel about that. Also, the real annoying cases switch levels more often, like (((R^μ)_ν)^ρ)_σ and there your proposal would still be nonergonomic

[subtle elbow]

Maybe there could be an additional parameter to math.attach that would prevent the grouping behavior.

[tawdry dock]

Conceivably you could create a package that took converts mathup string to typst math

[desert spire]

I intend to add support to math.attach for tensor notation. Cause its got mathml output equivalents and can be laid out using the opentype spec

I have no idea what the interface would be. Maybe have the attachments be able to take an array?

But this has nothing to do with adding some syntax for it

[desert spire]

E.g.

$ attach(R, tr: (mu, , rho), br: (, nu, , sigma)) $

[tawdry dock]

Wouldn't that require a mess of # and $?

[desert spire]

Uh probably? Idk. That seems like the only sane way to add it to attach tho

[tawdry dock]

The only syntax I could imagine being semi-ergonomic with how typst works currently would be something like $ attach(R;;;;mu,,rho;,nu,,sigma) $, though counting the semicolons would be annoying...

as evidenced by the fact that I think I missed one 😂

[desert spire]

Yeah that looks painful aha

If the semi colon syntax worked for named arguments that would make things more reasonable?

[tawdry dock]

how would that work though?

anyway @fresh horizon has done a lot of thinking about parsing I guess

[desert spire]

Good question. Aha

[fresh horizon]

I think you could just define an argument list that alternates top/bottom, and then maybe make use of math allowing empty args. Something like attach.alt(base, t, b, t t t, b b b, t)

Maybe call it like attach.rows or attach.rows.tb or even attach.tensor

[tawdry dock]

You also need to allow attachments on the left though?

I'm not super familiar with tensors

[sick lagoon]

Haven't seen tensors with indices on the left yet. Also this would be really confusing (Which indices belong to which letter in the output of R^μ_νρσ ^ν_ρR^σ_μ)

[sick lagoon]

I like this one

[knotty jolt]

?r

#let cL = math.cal("L")

If we use a normal $L$:
$ L (x) "vs" L(x) $

If we use $cL$:
$ cL (x) "vs" cL(x) $

What's the underlying reason? And is this considered a bug or intended? (I think it should not work this way.)

[tawdry dock]

It's because you defined cL using a string

which is interpreted as text

Do #let cL = $cal(L)$ instead

[knotty jolt]

?r

But `cal(L)` and `cal("L")` used to behave the same with respect to spacing. It's only different since `v0.14.1`. It was still the same in `v0.14.0` and before. Is this intended?

$gradient cal(L) "vs" gradient cal("L")$

$cal(L) (x) "vs" cal("L") (x)$

[knotty jolt]

I assume it's not indended because 0.14.1 should only fix things not introduce new behavior.

[fresh horizon]

Yes it is intended, this was done by PR 7276 for Issue 7270 due to PR 5738 creating SymbolElem to solve the upright single letter string problem in math: $"a"$ was the same as $a$, but not $upright(a)$

This is likely going to see updates in the new math.var changes being spearheaded by @desert spire in PR 7855