You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
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!)
The text was updated successfully, but these errors were encountered:
Search first
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:
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
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.
The text was updated successfully, but these errors were encountered: