The content of 1-dimensional horizontal matrices seems to always be slightly higher than before (this is especially visible in test issue-852-mat-type). Is this intended?

i'm not sure if it is intended or not. i can have a closer look in this weekend

i think it is intended. this pr set a minimal ascent and descent for each cell. and before that, the descent should be zero, and now it has a non zero descent. so things inside the matrix appears to be higher than before.

i'm not 100% sure though. i will experiement with this tomorrow

It it pretty close to KaTeX's behavior. and i think real latex should look similar to this

Great, then! Just wanted to make sure this wasn't an oversight.

One thing looks weird is that typst doesn't scale the delimiter like KaTeX does.

I need time to understand what \matrix in plain tex means

In plain tex there is no such padding. But plaintex ensures that the distance between each row's baseline is at least \baselineskip. There is also a padding in amsmath's matrix environment. So I mark this PR ready.

We should definitely use the row gap in my opinion. Though it's hard to decide to what. I think the current value was just a random on the spot decision that I thought looks good.

maybe we can keep it untouched at this moment?

That was a bad typo from me: I meant "definitely reduce", not "definitely use".

I personally perfer something between 0.1em to 0.2em. Maybe 0.2em is the best one. 0.1em seems to narrow in the 3 row matrix

#set page(height: auto)
#let testgap(..content) = {
  let arr = ()
  for i in range(1,11) {
    let row-gap = i * 0.05em
    let gapmat = math.mat.with(row-gap: row-gap)
    let res = [ row-gap = #row-gap \ #block(inset: 5pt)[#gapmat(..content)]]
    arr.push(res)
  }

  table(columns: 5, ..arr)
}

= 2d Display
$ testgap(a,b;c,d) $
= 2d Inline
$testgap(a,b;c,d)$
= 3d Display
$ testgap(a,,;,b,;,,c) $
$ testgap(a,f,dots;dots.v,b,g;dots.down,c,t) $
= 3d Inline
$testgap(a,,;,b,;,,c)$
$testgap(a,f,dots;dots.v,b,g;dots.down,c,t)$

KaTeX

I and @reknih like 0.2em as well. Could you maybe make another comparison image with uppercase letters and numbers, just for confirmation that these look good, too?

Here it is. I made a mistake in previous comparison image: seems that all of them are inline equations. New comparison code fix this.

#set page(height: auto)
#let testgap(isblock: true, ..content) = {
  let arr = ()
  for i in range(2, 7) {
    let row-gap = i * 0.05em
    let gapmat = math.mat.with(row-gap: row-gap)
    let res = [ row-gap = #row-gap \ #block(inset: 5pt)[#math.equation(block: isblock, gapmat(..content))]]
    arr.push(res)
  }

  table(columns: 5, ..arr)
}

= Display
$testgap(A,B;C,D;)$
$testgap(1,2;3,4)$
$testgap(a,b;c,d)$
$testgap(A,B,Z,X;W,Y,G,F;I,K,J,L;W,M,N,T)$
$testgap(a,,;,b,;,,c)$
$testgap(a,f,dots;dots.v,b,g;dots.down,c,t)$

= Inline
$testgap(A,B;C,D; isblock: #false)$
$testgap(1,2;3,4; isblock: #false)$
$testgap(a,b;c,d; isblock: #false)$
$testgap(A,B,Z,X;W,Y,G,F;I,K,J,L;W,M,N,T; isblock: #false)$
$testgap(a,,;,b,;,,c; isblock: #false)$
$testgap(a,f,dots;dots.v,b,g;dots.down,c,t; isblock: #false)$

Thank you! I think it all looks good, 0.2em it is!

I took a look at the changed test images and am a bit confused by how the row gap reflects there.

Why did the spacing in tests/ref/gradient-math-mat.png increase, but in tests/ref/gradient-math-misc.png it is suddenly super tight?

I find that some images becomes taller but some becomes shorter. I think this is because current padding only applies to matrices, but the default row gap not only controls mat but also influence vec. And vec doesn't has such padding logic at this moment. Similar case is that math.cases testcase becomes smaller. Let me see how to add padding for vec

Ah, that makes sense. I think adding the same logic for vec and cases (basically anything with row gap) makes sense.

Ah, that makes sense. I think adding the same logic for vec and cases (basically anything with row gap) makes sense.

Agree. I look at the code and I'm not pretty sure how to do it. cases and vec calls layout_vec_body, and it calls stack. It is stack that actually calculates the height, width and gap of boxes. I'm a little bit concerned that we may not be able to "hack it directly by using height.min()" because stack is also used by underover. Blindly do a min/max operation may have unexpected behavior for underover?

Maybe adding a parameter to stack that controls whether to do padding or not? I'm not quite convinced because it doesn't sound good

The important part is that matrix and vector behave similarly. Depending on which one turns out better in the code, a parameter in stack or a new from-scratch layout_vec_body would both work, I think.

I think i've understand what's happening.

interestingly, cases are still shorter than before, while matrices generally becomes taller than before. I need figure it out tomorrow
note in this case, the brace becomes taller

This PR did 2 things:

1. reduce row gap (-gap)
2. pad matrix row height to be at least as high as ( (+height)

This result in 2 change in tests: some matrices become taller, some become shorter.

• For those become taller: this is because the previous row height is smaller than (, and amount of +height is more than -gap
• For those become shorter: this is because each row is already pretty high, so the -gap has more impact on the final height.

Thank you! (Also for the quick conflict fix. :)