fenjalien / metro Goto Github PK

I try to use metro v0.2.0 in my document and found the unit "pascal" is not rendered correctly. Specifically, it is a little wider than normal (it seems that an extra space is added to the unit).

$ p_1 = qty(2.043,"pascal") \
  p_2 = 0.3268 "Pa" $

And the result is showed as below

Is that a designed behavior or a bug?

In the ltr examples, the output (left part) is not aligned with the source code (right part), like in Section 2.2 (commit d1d55a):

A possible fix is to wrap the raw() in a par() with a magic leading 0.9em:

--- a/manual.typ
+++ b/manual.typ
@@ -20,7 +20,10 @@
       )
     ),
     1fr,
-    raw(it.text, lang: "typ"),
+    par(
+      leading: 0.9em,
+      raw(it.text, lang: "typ")
+    ),
     1fr
   )
 }

The updated example (compiled on macOS) is as below:

The formatted number uses the wrong font, if the group settings are as in the following sample:

#import "@preview/metro:0.1.1": *

#set page("a4")
#set text(size: 14pt)
#show math.equation: set text(font: "Cascadia Code", size: 22pt)

#metro-setup(
  group-digits: "integer",
  group-separator: ".",
  group-minimum-digits: 4,
  output-decimal-marker: ","
)

#table(
  columns: 2,

  [Test 1:], [#num(1234500.23)],
  [Test 2:], [#num(0.000130)],
  [Test 3:], [#num(100)],
  [Test 4:], [#num(1000)],
  [Test 5:], [#num(1.2)],
)

As shown in the resulting table, Test3 and Test4 are formatted with a different font. This seems to happen, if the length of the number is smaller than the defined group-minimum-digits and no significant fractional decimal places are given. Test5 shows, that even a short number is formatted right, if significant (>0) decimal places are in the fractional part of the number.

I imagine this would work as #unit("hertz per sqrt kilo watt hour") (a very useful unit)
This would also come with a sticky-sqrt option

It would be nice to be able to set the number of decimal digits or the number of significant figures as an option in the num and qty function. When displaying results in a table or importing data from external files, sometimes you want to adjust these parameters without loss of accuracy in the underlying data.

Section 2.3.1 in phrase; typo 'othre'.
Towards the end of the section 3 first paragraph; confusing grammar.
Section 4.3 Powers first paragraph; two typos.

Hi y'all.
Great crate, I'm already loving it.
What do you think about allowing stuff like

#num("2.3^(28)")

or

#num()[2.3^(28)]

Even greater would be

#num(2.3^(28))

But I think that's not possible since ^ is invalid in code. From typst output

error: the character `^` is not valid in code

Or maybe just a pw keyword to allow for adding powers to the number?

Or maybe it's not even necessary. Looking forward to your answers.

I suggest adding the following units:

In case you don't know about binary prefixes see https://en.wikipedia.org/wiki/Byte#Multiple-byte_units

As per title, num-range would be an excellent addition

It would be much more convenient to be able to write

#num[3e12]

and get equivalent of the current

#num(e:12)[3]

• Easier to type
• Easier to copy to and from source code, scientific software output, etc.

Note:

Currently, you can type

#num(3e12)

But this will show the number in decimal notation 3000000000000 instead of exponential scientific notation.

For the reference, package unify allows the following

 #num("3e12") 

Setting per-mode = "symbol" removes the quantity product. Writing

23    num(number, e: e, pm: pm, separate-uncertainty: separate-uncertainty, separate-uncertainty-unit: if separate-uncertainty == "repeat" { u }, ..options)
24    quantity-product    // inserted
25    u

in qty.typ solved the issue in my case.

It seems that #num(42.0, minimum-decimal-digits: 2) doesn't work as expected, rendering as $42$ instead of $42.00$.

As a side note, and I realise this might be deliberate for consistency with siunitx, but it would be great to have an option decimal-digits as well as minimum-decimal-digits, which behaves like the sprintf format %.*f. As it stands, I can't figure out how to format an arbitrary number to an exact number of decimal places without using oxifmt (e.g., #num(strfmt("{:.2}", 42))) -- but it seems a bit silly to load both packages for this!