Search first

• I searched and no similar issues were found

This is a duplicate of #9787, but the bot closed this issue as not planned. I still believe this is a bug that is worth fixing for improved usability. I couldn't find a way to reopen the ticket, so I've recreated it as a new one.

What Happened?

Tables with math contents seem to get very large widths. It seems like Logseq is expecting a very wide column, even though the content is actually very short. Compact tables only seem to help to reduce vertical padding, not horizontal. Additionally, max-width property doesn't seem to do anything (related: #9485)

Example:

| $\downarrow$ (to) / (from) $\rightarrow$ | A  | B      | C     |
|------|---------|---------|---------|
| A | /     | $1 \: \Omega$ | $1 \: \Omega$ |
| B | $1 \: \Omega$ | /      | $1 \: V$ |
| C | $1 \: \Omega$ | $1 \: \Omega$  | /     |
logseq.table.version:: 2
logseq.table.hover:: both
logseq.table.compact:: true
logseq.table.max-width:: 1

This table becomes so wide that I get horizontal scrolling bars by default. Removing the Latex math from the table seems to help. Then the table automatically resizes so that no scrolling is necessary, even when placing it in a hierarchy (so it has less horizontal space)

Reproduce the Bug

1. Create table with following code:

| $\downarrow$ (to) / (from) $\rightarrow$ | A  | B      | C     |
|------|---------|---------|---------|
| A | /     | $1 \: \Omega$ | $1 \: \Omega$ |
| B | $1 \: \Omega$ | /      | $1 \: V$ |
| C | $1 \: \Omega$ | $1 \: \Omega$  | /     |
logseq.table.version:: 2
logseq.table.hover:: both
logseq.table.compact:: true
logseq.table.max-width:: 1

2. Create the same table, but with placeholders for the latex math:

| X (to) / (from) X | A  | B      | C     |
|------|---------|---------|---------|
| A | /     | 1 X | 1 X |
| B | 1 X | /      | 1 X |
| C | 1 X | 1 X  | /     |
logseq.table.version:: 2
logseq.table.hover:: both
logseq.table.compact:: true
logseq.table.max-width:: 1

Note how different the behaviour is. The first column is extremely wide for the first column and the table doesn't scale according to the hierarchy, even though the second table does

Expected Behavior

Tables should allow for math formulas to be used and take the rendered width into account.

Screenshots

Rendered view of both tables. Ideally, they would both act very similarly as the width of the content is nearly identical

Desktop or Mobile Platform Information

App Version: Originally noticed in 0.9.10 - not fixed in 0.10.5 or in between versions
Git Revision: 16c472b
Platform: Mozilla/5.0 (Windows NT 10.0 Win64 x64) AppleWebKit/537.36 (KHTML like Gecko) Logseq/0.9.10 Chrome/104.0.5112.124 Electron/20.3.8 Safari/537.36
Language: en-GB

Windows 10 22H2

Additional Context

No response

Are you willing to submit a PR? If you know how to fix the bug.

• I'm willing to submit a PR (Thank you!)