# Not rendering inline math properly in reading view

Obsidian does not render inline math (e.g., $\bar{r}$ or $\hat{r}$) properly in reading view when:

• the inline math starts at the beginning of a line and
• there are at least 29 lines in the note.

It works fine when the note has less than or equal to 28 lines, or the inline math is in the middle or at the end of a line.

### Steps to reproduce

1. Open a new page.
2. Type the following 29 lines:
$\hat{r}$ 1
$\bar{r}$ 2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

1. Press Cmd-E. (You can see that $\hat{r}$ and $\bar{r}$ are not properly rendered. Both are rendered as $r$.)
2. Edit the page to remove the last line (29th).
3. Press Cmd-E. (This time, $\hat{r}$ and $\bar{r}$ are properly rendered.)

### Environment

• Operating system: macOS 12.0.1
• Debug info:
SYSTEM INFO:
Obsidian version: v0.13.19
Installer version: v0.13.19
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: light
Community theme: none
Snippets enabled: 0
Safe mode: on

RECOMMENDATIONS:
none

works for me. Post a screen recording of this happening in the help vault. Thanks.

I made a screen recording, but I couldn’t find a way to attach it (.mov) though.

Another way to reproduce the issue (on MacBook pro 13 inch) is

1. Open a new note.
2. Enter full screen mode (by pressing the green button on the top-left corner of the window).
3. Press Cmd-E and switch back and forth between the edit and reading view.

It seems like the issue is related to the window size; if I

1. set the current view as reading, and
2. make the window full on the screen,
3. start resizing the window by dragging the left-side to the right slowly,
then the bar or hat in the inline math appears and disappears based on the location of the left side.

Forgot to add the step “Type the 29 lines (in the steps-to-reproduce section) on the note” after Step 1 “Open a new note.”

I can’t reproduce it. From your description it sounds like a crazy rendering glitch that only happens under some circumstances. We have no control at this level. So let’s hope that chrome (which we use for rendering) finds this bug and fixes it.