Table alignment for quantities

[lluchs]

#ztable(
  columns: 1,
  format: (auto,),
  zi.m(1), zi.m(1.5), zi.m(20),
)

It would be nice if the numbers would align here as they would without the unit.

[Mc-Zen]

Hello @lluchs ,

Unfortunately for your case, this is not intended to work. For once, the unit for quantities in tables is normally just shown in the column header (e.g., "length in m") and not in every cell.

For another, we cannot currently detect units in a table, at least not in a sensible way. This is the same thing as num instances explicitly inserted into a table (instead of just a string or content) - these are also not being aligned.

Once num and quantities become types, it would be possible to detect this case but I'm still not sure whether this is a common enough (for the reason above) use case to justify the considerable extra implementation effort. Except, if the unit would be placed into the number under the suffix argument.

[lluchs]

Yeah, I figured from looking at the code that detecting this reliably with the way the units currently work would require custom types.

I'm putting the units within the table cells because they're byte amounts with different magnitudes (GiB, MiB, KiB). I suppose the supported way would be to write $10 \times 2^{30}$ instead of 10 GiB, but formatting byte amounts like that is uncommon.

[Mc-Zen]

Okay, this actually a very reasonable case and I will consider that when types come to Typst and Zero gets an overhaul.

For now you could pass [10#nonum[GiB]] instead of using units which will enable correct alignment.

[thriveth]

I am currently writing a table of physical constants and conversion factors in a compendium for my students (I am teaching graduate level astrophysics). I such a table, each row basically has its own - sometimes quite involved - mixed units. At the moment, I can work around it by having the units in a separate column if I want to, but it's not ideal.

I also sometimes make similar mixed-unit "overview" tables in journal papers.
I understand if it is not practically doable at the present time, but I certainly think there are valid use cases for it, so I hope it will stay on the road map.

[Mc-Zen]

I believe (with a stress on believe) that an implementation will be possible when zero becomes based on types. When this is done, I want to allow not only conversion of string numerals in tables to num (which is currently done) but also alignment of num instances that are explicitly by the user put into the table. Then the same can be supported for quantities.

However, currently num is just a function returning arbitrary content and the table cannot recognize when it encounters a "num" or "quantity.

That being said: yes, it's still on the roadmap!

[TabError]

I would also like this feature.

I am currently using zero to format money values. (Maybe this is a slightly different usage than the package intends, but i haven't found any other suitable option in the current typst eco-system. If you have alternatives I'm looking forward to recommendations)

So I currently use the package like this:

// these blocks are spread into the table
#[#s#zero.nonum[€]]

// and this is used to format the table
#let num_formatting = (digits: 2, math: false, decimal-separator: ",")
#show table: zero.format-table(none, none, none, none, none, num_formatting, num_formatting)

And with this i get a table like this:

All numbers nicely aligned at the , and padded with zeros but still centered in the column.

With the feature discussed here it could just boil down to this:

// declare a money unit
#let money = zero.zi.declare("€").with(digits: 2, math: false, decimal-separator: ",")

// this as content
#[#money(s)]

// this as alignment rule
#show table: zero.format-table(none, none, none, none, none, auto, auto)

But currently this looses the alignment:

[Mc-Zen]

Hi @TabError ,

thank you for posting your usecase for this feature. This helps me sort priorities for Zero.

Unfortunately, as written in my previous response in this thread, we need to be a little patient since this feature relies on user-defined types becoming available with Typst. This will definitely come but the Typst team is currently still busy with other features.