Why does a display equation break a paragraph?

Questions
,
1

I found that the “display” equations themselves also break paragraphs. For example,

#set par(hanging-indent: 3em)
#lorem(50)
$ display(y=a x + b) $
#lorem(100)

This code block is renderred as

image

The output would not change even with the following code

#lorem(50) $ display(y=a x + b) $ #lorem(100)

However, a “display” equation should be a part of a paragraph, if there is no blank lines around it. This is also how LaTeX and Word deals with display equations.

P.S. To be honest, I’m afraid the priority of the paragraph now is a bit too low. Anything showing by a block can break the paragraph.

2

The break actually appears because you’re using block math $ ... $ instead of inline math $...$ (notice the spaces on the left and right).

This

#lorem(50) $display(y=a x + b)$ #lorem(100)

will render as
image

3

From what I understand, you do want the equation to be separate in terms of a new line, but the paragraph should remain the same. As you already assumed correctly, all block level elements currently break the paragraph, so this isn’t really possible at the moment.

If you really want to, you can work around this by wrapping the equation in a box and adding line breaks manually. The following may not work well when the equation is at the start or end of a paragraph, but then you can also just use normal equations.

#set par(hanging-indent: 3em)

#let par-equation(eq) = {
  linebreak()
  box(inset: (y: 0.5em), width: 1fr, eq)
  linebreak()
}

#lorem(50)
#par-equation($ a + b $)
#lorem(50)

1000015136
10000151361116×896 191 KB

1 Like
4

Oh I see, I wonder if there are any good arguments for either case, i.e. merging the paragraphs vs keeping them separate.

I reckon it would have positive impact in most cases to actually merge math blocks into its surrounding paragraphs, if there’s no issue for this you could create one.

5

Could you elaborate on this?

6

If a block equation is semantically part of a paragraph, as was intended here, then the current behavior introduces a parbreak regardless of intention. Depending on set and show rules in effect this could then cause a few hiccups:

  • For first-line-indent being set this, the next paragraph to get and indentation even when the user did not intend so.
  • Spacing would likely be incorrect.
  • Something like tagged PDF export would not place the correct tags, resulting in the paragraph being split up for the PDF reader too.

So, I’m thinking, perhaps we should treat math blocks as part of a paragraph unless a parbreak is explicitly added, i.e.:

#[
  Markup
  $ block $
  Markup
]

// becomes

#par[
  Markup
  $ block $
  Markup
]

and

#[
  Markup
  
  $ block $
  
  Markup
]

// becomes

#par[Markup]
$ block $
#par[Markup]

At least for me, math is often used in a flow of text without intention of breaking up the surrounding paragraphs, just like shown in the question.

Somewhat related, we also treat the spacing for lists differently depending on the previous line:

Markup
- List

// is not the same as

Markup

- List

An alternative could be simply wrapping the whole paragraph in par of course:

#par[
  Markup
  $ block $
  Markup
]
4 Likes
7

Indeed in books display math is usually part of the paragraph, it’s even common for it to appear in the middle of a sentence. Some random examples:

Spivak’s calculus:

image

Bishop’s Pattern Recognition and Machine Learning:

image
image743×234 126 KB

So I agree that display equations $ ... $ should not start a new paragraph by themselves.

3 Likes
8

This is essentially the same as this issue (though I originally phrased it for lists)

9

I agree with you. I think this should be a language-level feature, although we can create something like the environment equation in LaTeX to wrap our equations. Moreover, if you want to display equation numbers, there would be another issue,

image
image694×262 84.9 KB

We need extra effort to adjust the numbers.

10

I think so. As I said, the priority of the paragraph seems to be too low and a block can easily break the paragraph flow. But fixing this would be a breaking change. I’m afraid that it would not happen in a short time.

11

Looks like you used box(width: 100%) instead of box(width: 1fr).

12

Thanks. I finally figured out how to fix this issue.