I agree that it is unexpected and inconsistent. Since there is already a way to create the italic character (no quotes), it would be better to make characters inside quotes behave consistently.

Find the same issue when I was trying #let dd="d" for differential and felt surprised on this behavior...

Find the same issue when I was trying #let dd="d" for differential and felt surprised on this behavior...

BTW, for differential you can just use dif.

FYI

I would like to add that I was also surprised by this behavior when trying to write units that use special symbols / Greek letters: $R = 50 med "k" Omega$ displays the k in italic. The alternatives are $R = 50 med upright(k) Omega$ or

#let kohm = "k"   sym.Omega
$R = 50 med kohm$

If we said, ok, text in quotes is upright, text without quotes is italic (or vice versa) and text with a # prepended is a variable, this would clarify things and also improve the two-letter unit parsed as variable situation where it at least still compiles but just looks wrong instead of refusing to compile.

If we said, ok, text in quotes is upright, text without quotes is italic (or vice versa) and text with a # prepended is a variable, this would clarify things and also improve the two-letter unit parsed as variable situation where it at least still compiles but just looks wrong instead of refusing to compile.

I agree with the first half, but having the non # variables in math mode are quite nice if you have a bunch of arg max sum ...

A more recent pointer

It looks like a bug, but curiously the current behavior does not break what the doc (https://typst.app/docs/reference/math/) says:

In math, single letters are always displayed as is. Multiple letters,
however, are interpreted as variables and functions. To display multiple letters
verbatim, you can place them into quotes and to access
single letter variables, you can use the hash syntax.

If we want to display quoted single letter as normal text too, as suggested in this issue (and I agree!), Typst should promise this instead:

In math, single letters are always displayed as is. Multiple letters,
however, are interpreted as variables and functions. To display letters
verbatim like normal text, you can place them into quotes; to access
single-letter variables, you can use the hash syntax.

So.. do we want this? Bringing to @laurmaedje 's attention.

More on impl:

Inside math i.e. $ ... $, "a" and "aa" are parsed as SyntaxKind::Str and thus Value::Str, and an unquoted v is a Value::Content holding a Text(v), so Typst originally has enough knowledge to render a and v differently. However, in math's eval phase, ExprExt::display_ext() calls Value::display(), which converted both Values to Contents that are downcastable to Packed<TextElem>, effectively erasing this distinction. Therefore, when MathContext::layout_text() runs with Packed<TextElem>, it doesn't know single-letter a and v actually came from different syntax/value kinds.

One idea is that during the math eval phase, when Value::display() constructs the TextElem from Value::Str, it should specifically request a normal font style. However, it's not trivial to do so because TextElem::style: FontStyle is a #[ghost] field, which "cannot be set on an individual instantiated element, and must be set via the style chain", so this direction looks like a rabbit hole.

(FYI, #1125 is a larger-scale overhauling FR that is sufficient to address this issue - but not sure if that FR is necessary if we just want to fix this issue)

One idea is that during the math eval phase... this direction looks like a rabbit hole.

Hmm, not rabbit hole after all? I seem to have made it work by carving out a special case during the math eval phase's eval_display(). This special case utilizes the aforementioned "knowledge to render a and v differently" right before the knowledge is erased.

impl ExprExt for ast::Expr<'_> {
    fn eval_display(&self, vm: &mut Vm) -> SourceResult<Content> {
        let value = self.eval(vm)?;
        let content = match value {
            Value::Str(_) => {
                value.display().styled(EquationElem::set_italic(Smart::Custom(false)))
            }
            _ => value.display(),
        };
        Ok(content.spanned(self.span()))
    }
}

Result:

$ 1 "ft" = 0.3048 "m" \
  A = pi r^2 $

(If this direction is right, it still needs polishing to make the spacing right -- note "0.3048" and "m" are adjacent without a space, unlike "1" and "ft")

@Leedehai Forcing upright at that point would unfortunately break the italic function:

$ 1 "ft" = 0.3048 "m" \
  A = pi r^2 italic(a   "beta") $

(Just italic("beta") continues to work because it doesn't use that code path, which would add extra inconsistency.)

I consider this issue a bug or at least something that's not desirable, but I'm not sure whether we can properly fix it without something like #1125.

Agreed.

Further, special-casing Value::Str could over-apply the italic-to-upright fix, because it turned out the let bindings with strings and function param names are collected as Value::Strs, too, and thus when they are embedded into $..$ they would be made upright by this fix, which is a mistake.

Barring an overhaul like #1125, it looks an appropriate limited-in-scope fix should start from the parsing phase. The knowledge of different Value types in the evaluation phase is not sufficient to implement this fix.

Yes, I think there could even be added a new element type math.lit for these literals which could even facilitate special styling or overriding the default upright style.