Discussion: Inline equations

[SolidTux]

I'm also trying to build a grid system for a document. It's still changing constantly and entangled in a big document (and mangled without some LaTeX-like DIV calculation and leading calculation), but at some point I think it would make sense to consolidate efforts. In general, I have a very similar ansatz with setting top-edge to the wanted line height.

The main paint point for me currently are inline equations. I don't think there is an optimal solution as long as there's no way to get information about their baseline. I see that you are currently basically ignoring larger inline equations with this:

#show math.equation.where(block: false): it => box(height: line-height, it)

In LaTex, the grid package seems to also break with larger inline equations from my experiments.

I think, in general, it would be good to allow larger equations, but I didn't manage to get consistently good results so far. This is my best attempt so far (line-height is the quatization step):

#show math.equation.where(block: false): it => {
  let size = measure(it)
  let lines = 2 * calc.ceil(0.5 * size.height / line_height) - 1
  let frac = size.height / line_height - lines
  box(
    height: lines * line_height,
    baseline: ((lines - 1) / 2) * line_height,
    fill: if draft {
      red.transparentize(75%)
    },
    it,
  )
}

which results in this:

While some things are fine, the larger sum, for example, is broken.

Do you have any ideas how to handle this better?

[ssotoen]

Good to see I’m not the only one who cares about grids!

The problem is that Typst intentionally shrinks the bounding box of inline math in order to prevent the line height from fluctuating too much (typst/typst#1028). This means it’s literally impossible for us to measure the height accurately, which you can see in the attached picture. Display math works fine, inline does not.

I do like your idea of setting the boxes to a height that fits their content but until Typst’s handling of this is improved I don’t think it’s going to work.

While thinking about your suggestion I came up with a different idea. We could wrap paragraphs with overheight math in a function that takes a extra-lead parameter (which the user unfortunately would have to supply manually). We could then measure the height of the whole paragraph and calculate its leading property to be at least extra-lead but adjusted so that the paragraph after it aligns with the grid again. The user would need to experiment with different values until the math fits. This paragraph wouldn’t stick to the grid perfectly but everything around it would, and its lines would be consistently spaced without any huge gaps. Something like this:

What do you think?

[SolidTux]

That's not a bad idea, for sure. Occasionally, it might also be fine enough to allow things to align with 0.5*line-height.

The shrinking of the bounding box is not that big of a problem, as it's proportional to the leading (currently 0.7*leading from top and bottom each). At least my solution sets the leading to 0 anyway.

I played around a bit with a variation of your suggestion a bit here. There are two options:

• use_max_height: true one measures the largest inline equation and adds this to the line height
• use_max_height: false the other one measures the size difference of the content with and without inline equations (they are replaced with a zero-height box with the same width)

With manually choosing the appropriate one, I get quite decent results.

[SolidTux]

Not that due to layout(...) wrapping things in a block, one might need to add an empty box() afterwards to fix first-line-indent.

[SolidTux]

I slightly updated the project to shift the paragraphs up a bit to have them sit a bit more nicely in the gap.