\ohm does not work with newtxsf package

[PrometeuszJasinski]

Great package and I'm currently moving from v2 to v3 where an issue came up: When I load the newtxsf package, the Omega is not displayed correctly with pdflatex. It is just a ' symbol in the output.

\documentclass[11pt, dvipsnames, oneside]{article}

\usepackage{geometry}
\usepackage[utf8]{inputenc}
\usepackage{siunitx}
\usepackage[T1]{fontenc}

%\usepackage{newtxsf} % ohm does not work with newtxsf
\begin{document}Enjoy writing your document!

\qty{2}{\kilo\Omega}

\qty{2}{\kilo\ohm}

\qty{2}{\micro\metre}

\qty{2}{\percent}

\qty{2}{\degreeCelsius}

\qty{2}{\degree}

$\omega$ $\Omega$
\end{document}

Any ideas how to restore this?

[daleif]

Did you try moving newtxsf up before loading siunutx?

[josephwright]

Did you try moving newtxsf up before loading siunutx?

That in itself is a bug ... which I'll look at :)

[PrometeuszJasinski]

Thanks for the quick support. Yes, it works. It seems like T1 must also be last, cause the below order does not work either. Sorry that I'm not used to care about the order of inputs based on my c++ background.

\usepackage{geometry} \usepackage[utf8]{inputenc} \usepackage[T1]{fontenc} \usepackage{newtxsf} \usepackage{siunitx}

[josephwright]

Sorry that I'm not used to care about the order of inputs based on my c++ background.

Ideally it shouldn't matter - the LaTeX team have provides some tools to improve this, and I will look to avoid the issue

[PrometeuszJasinski]

Really appreciated!

[josephwright]

The ordering issue is out of the control of siunitx: it relates to how newxsf sets up fonts dependent on encoding:

\documentclass{article}
\usepackage{newtxsf} % Comment here for a difference
\usepackage[T1]{fontenc}
\usepackage{newtxsf}
\begin{document}
$\mathrm{\Omega}\mathrm{\upOmega}$
\end{document}

[josephwright]

Basic issue here is that siunitx places each unit inside \mathrm (as standard), and with the T1 encoding loaded, newtxsf gives problematic output for \Omega and \upOmega in that case. I will therefore have to check explicitly for the package and use an alternative definition: coming up.

[josephwright]

See https://github.com/josephwright/siunitx/issues/435 for discussion of the semantics of \mathrm and its relation to non-Latin symbols.

[josephwright]

Sorted but I have to say the package does itself no favours: try

\renewcommand{\familydefault}{\sfdefault}

before or after loading it and find ... pain with \mathrm.

[PrometeuszJasinski]

I’m the last one to complain and happy to hear a workaround. Thanks!

[josephwright]

I've had a mail from the package author: he's fixed at his end. Looking at the issue, that's the better approach, as what I was thinking of is a work-around. I'd rather avoid that if possible, so will back out my change - you can always apply locally.

[PrometeuszJasinski]

What a great community. Thanks!