siunitx
siunitx copied to clipboard
\Omega, etc., should not be directly in \mathrm
Although \mathrm
is essentially 'upright', it can cause issues, for example
\documentclass{article}
\usepackage{helvet}
\renewcommand\familydefault{\sfdefault}
\usepackage{mathastext}
\begin{document}
$\mathrm{\Omega}$
\end{document}
For this and for semantic reasons, the 'normal' \mathrm
should therefore be suppressed/avoided with non-Latin symbols. Probably this is best done using \mbox{$...$}
as a general construct.
Probably \text{$...$}
instead of \mbox
to get correct sizes.
Actually, I'd rather set up to suppress the \mathrm
in the first place: I have an idea but it may take a day or two.
On the other hand, something like isomath
needs \mathrm{\Omega}
to be upright ... and that's before you worry about unicode-math
Well, and a combination of mathastext
and isomath
need again something different (because there \mathrm{\Omega}
will again not work).
@egreg suggests that \mathrm{\Omega}
'should' be OK - I'm going to consult with @wspr and @frankmittelbach I think.
@josephwright — don't ask me, I don't think we can build a completely general and scaleable system using the 2e ideas of the \mathXX
family of commands.
I don't really understand the context of this issue, though. When you talk about \mathrm{\Omega}
, are you actually referring to the Ohm unit? Seems like to do it in a general way you need to introduce all sorts of special-case code since you can't rely on having a unicode font with U+2126. Can that be handled using NFSS font commands instead?
@wspr I'm working on ohms but there is a more general point. I can arrange for various things to be used as the result of \ohm
, and I do depending on what packages are loaded. More generally, I document that users might have to adjust the output depending on what font they use.
What I'm trying to get at, though, is the 'standard' setting expectation. Is \mathrm{\Omega}
meant to work, and is it semantically correct? I guess what I mean is does rm
here mean only Latin letters, or is it more generally 'serifed style'. It's not clear to me as \mathsf
certainly does apply to \Omega
but \mathbf
doesn't, while of course Omega isn't a 'roman' character at all ...
Depending on what is 'right', I should either format
\qty{10}{\ohm\metre}
as
$10\,\mathrm{\Omega}\,\mathrm{m}$
or
$10\,\Omega\,\mathrm{m}$
(I'm pretty convinced that \mathrm{m}
is the correct representation for metres, as opposed to \textrm
or something like $10$\,m
.)
@wspr Then of course I have \mathrm
vs \symrm
if fontspec
is loaded ...: I'm reasonably confident I want \mathrm
in all cases, as if a user switches to sanserif, \symsf
would be wrong!
@josephwright — my broad understanding of \mathrm
is that it implies "use the text roman font for (ascii) alphanumeric symbols. Since \Omega
is not a text symbol but a maths symbol, it is unaffected by being placed into \mathrm
. (There is a funny edge case or two but I think that's the gist of things.) In a Unicode font, I would expect \qty{10}{\ohm\metre}
to typeset \ohm
in a text font using either U+2126 or U+03A9 — not from a maths font.
For your question, the following two lines will (I believe) always yield the same output:
$10\,\mathrm{\Omega}\,\mathrm{m}$
$10\,\Omega\,\mathrm{m}$
You could imagine an alternate universe where \Omega
is redefined to refer to a text font if not used in maths.
Going back to this specific example. I can't help but think you should be using \textohm
in some way:
\documentclass{article}
\usepackage{amsmath}
\begin{document}
\bfseries\itshape
$10\,\text{\textohm}\,\text{m}$
\end{document}
The bf+it style just to emphasise the difference between a standard \Omega
, which should never respond to text font changes.
Considering \Omega
is defined via LGR
encoding, then \mathrm
will also print an unexpected result:
\documentclass{article}
\DeclareFontEncoding{LGR}{}{}
\DeclareSymbolFont{upgreek}{LGR}{opensans-TLF}{m}{n}
\DeclareMathSymbol{\Omega}{\mathalpha}{upgreek}{87}%
\usepackage{siunitx}
\begin{document}
$\Omega$
$\mathrm{\Omega}$
\unit{\ohm}
\end{document}
LGR is a troublesome encoding that doesn't obey the encoding specification (even though it is widely used) and therefore has limitations. Anyhow, you can't declare a symbol as \mathalpha
if it isn't in all math alphabet fonts in the same position (or else you can't use it with different alphabets and
\DeclareMathSymbol{\Omega}{\mathalpha}{upgreek}{87}%
exists only in "upgreek" so your result is not at all surprising if all other math fonts have different layouts. In that case it should have been a \mathord
.
@mrpiggi The thing here is that I've still not got a clear idea of what is 'right' here, with the added complexity that the answer possibly depends on whether Unicode fonts are being used. That's why I've not 'fixed' - I'm not truly sure I know what the right thing is.
@FrankMittelbach thanks a lot, this solves at least my issue ;)
To recap, the situation with basic TeX is a bit blury but essentially it is like this (in NFSS convention):
- there are a number of "math alphabets". These come actually in two flavors:
- full alphabets (which are rm, sf, bf, tt,...)
- special alphabets (cal, frak, ...)
- full alphabets are supposed to implement all symbols declared as
\mathalpha
- special alphabets vary, often they only implement A-Z, sometimes a-z and 0-9 sometimes a few more chars and the rest goes belly up
\documentclass{article}
% default (assumes OT1 in operators and in the math alphabets):
% \DeclareMathSymbol{\Omega}{\mathalpha}{operators}{"0A}
\begin{document}
$\Omega \mathrm{\Omega} \mathbf{\Omega} \mathsf{\Omega}
\mathit{\Omega} \mathtt{\Omega} \mathcal{\Omega}$
\end{document}
If the NFSS math setup is changed, e.g. T1 is used in "operators" and in mathrm etc, then obviously the declaration for symbols need to point somewhere else (or the math setup is broken).
And \Omega
reacts correctly to \mathbf
by default, not sure why it doesn't for @josephwright

@mrpiggi The thing here is that I've still not got a clear idea of what is 'right' here, with the added complexity that the answer possibly depends on whether Unicode fonts are being used. That's why I've not 'fixed' - I'm not truly sure I know what the right thing is.
what do you mean by "unicode" fonts are used? Used where/when?
@FrankMittelbach When unicdoe-math
is loaded - you then have the \sym...
versus \math...
split, and it's just not the same as the classical LaTeX setup.
@FrankMittelbach Sorry for the confusion on \mathbf
: I was thinking of other non-Latin symbols.
As you say, with a 'vanilla' setup, \mathrm{\Omega}
is the same as just \Omega
, so arguably I am OK using \mathrm
around all of the unit output. The issue arises as lots of 'apparently OK' setups don't actually work like the out-of-the-box one.
Well they are ok as long as nobody attempts to use the symbols in alphabets :-)
But for a general approach I'm not sure your symbols should be set as straight math. They are kind of in between. For example formulas in heading should normally not come out bold or sf just because the surrounding text font is bf or sf, for your units that not so clear. It is also not clear if they should be using text fonts or math fonts both of which aren't necessarily the same. But it is too late tonight ot think about this further (and probably not during the next days either ... have a workshop to prepare :-))
But for a general approach I'm not sure your symbols should be set as straight math. They are kind of in between. For example formulas in heading should normally not come out bold or sf just because the surrounding text font is bf or sf, for your units that not so clear. It is also not clear if they should be using text fonts or math fonts both of which aren't necessarily the same. But it is too late tonight ot think about this further (and probably not during the next days either ... have a workshop to prepare :-))
Oddly, I've thought about this quite a bit :)
The 'rules' for quantities (BIPM/NIST) are clear that they are mathematical in nature and tend to specify mid-weight and upright. To me that suggests strongly that in TeX terms they come out as $10\,\mathrm{kg}$
or similar as standard. The package handles the cases where
- People want to stick to math mode but apply a font change (
\mathsf
, leaving math version 'unchanged' if\boldmath
or\sansmath
are active, etc.) - People want to use text mode (with or without control of family/weight)
So it's not so much the final outcome that's tricky as the 'standardised' form. (The printing routine replaces \mathrm
with something appropriate if that's what's needed, for example simple removing it entirely when printing in text mode.)
That brings me back of course to the opening statements here. I can (moderately) happily arrange for the \mathrm
to be omitted around non-Latin symbols, but that's a pain and I'd rather not if it's not necessary. I'm still stuck really with the fact that \mathsf
is I think nice and clear (it is reasonable to put \Omega
inside it), but \mathrm
is more complex.
@FrankMittelbach If you look at the history of siunitx
I used to favour the equivalent of $10$\,m
(units as strictly text), but in the end I decided that was not really in line with what I'd hope a user would type in 'by hand'. (Particularly with v3, I'm aiming to actually produce the same 'basic' LaTeX as the user would actually type manually, then typeset that.)
I think if we were to take about fundamental philosophy here, yes units belong in the text font that is associated with maths (i.e., de facto \mathrm) but as units should always be text themselves things like \Omega would be better to call an error message or silently ignore the \mathrm state. E.G., what does \mathrm{=} “mean”? I think most people would assume the = comes out unchanged.
Where there are symbols in units that often come from maths mode (micro, ohm, etc) but should respect the differences between \mathrm and \mathsf and \mathbf, etc., there should be corresponding \textXY symbol commands defined for them to do the right thing.