Improved rtl support
emilyyyylime opened this issue · 8 comments
tablex's align argument supposedly takes into account the context of the table when set to auto (the default), but seems to default to left even with text(dir: rtl).
Furthermore, the order of the columns goes left-to-right, and I could not find any way to override that behaviour (unlike align, which only requires a simple align: right).
Okay I've figured out map-rows: (idx, row) => row.map(c => (..c, x: 4 - c.x)) as a temporary workaround, but the core issue still stands I believe
How does the default table behave for your specified use cases?
(Also, you can try align: start for text direction-aware alignment)
align: start has the same effect as align: right with rtl text, it seems to be a more sane default if you ask me.
The default table has the behaviour I described as expected, with the column order following the text direction order.
Oh and trying to make rowspans work with this is an absolute pain. I'd go ahead and say it just should not be attempted until a proper fix for this is implemented
I see. Unfortunately, we cannot currently detect if text was set to RTL (blocked by typst/typst#763), but we could add a rtl: bool toggle.
As I see it, however, the ideal way to tackle this would be to change the order of columns in your own data. It seems a bit weird for me for the table to produce output in a different order than the parameters it received (at least assuming we are using auto-positioning). Still, we could investigate adding this down the road. Thank you for reporting!
It seems a bit weird for me for the table to produce output in a different order than the parameters it received
Problem is, from the perspective of a native rtl-language speaker, in a rtl document — this describes the current behaviour. If I'm working with numerical data, sure; but if my table contains rtl text, I expect cells to be added right to left. The current behaviour is the one that produced output in a different order than the table received
I see, thanks for the info. I think it could be reasonable to add a toggle for this, though the implementation might get a bit complex for spans. I'll have to give this some further thought.
Great! Thanks for looking into this