Interaction with siunitx can produce mangled characters (encoding mismatch?)

[nxg]

Consider the input file:

\documentclass{article}
\usepackage{stix2}
%\usepackage[not1]{stix2}
\usepackage{siunitx}
%\usepackage{siunitx}[=v2]
\begin{document}
\SI{1}{\micro\metre}
\end{document}

Processing this with

$ xelatex stix-siunitx.tex
This is XeTeX, Version 3.141592653-2.6-0.999993 (TeX Live 2021) (preloaded format=xelatex)
 restricted \write18 enabled.
entering extended mode
(./stix-siunitx.tex
LaTeX2e <2021-06-01> patch level 1
L3 programming layer <2021-10-18>
(/usr/local/texlive/2021/texmf-dist/tex/latex/base/article.cls
Document Class: article 2021/02/12 v1.4n Standard LaTeX document class
....

I get the attached result: stix-siunitx-bit.pdf. Here, the \micro produces a hooked ‘t’ rather than a mu glyph. I see the same behaviour with LuaLaTeX (LuaHBTeX, Version 1.13.2 (TeX Live 2021)). Running this with pdflatex or using either of the alternative \usepackage commands above, produces the expected or desired result.

I at first thought this was a bug in siunitx, but issues 547 and 550 on the siunitx bug tracker indicate that the problem is a mismatch between v3 of siunitx and a few other packages, including stix2. Regarding this, the siunitx maintainer mentioned that:

in v3 I've taken a more definite line about the encoding expectations: stix2 is as-standard forcing T1, but that's inappropriate for a Unicode engine.

This explains why the [not1] option works, but I'm not sure what fallout that may have, in terms of other encoding problems.

I know enough about encodings to appreciate the general problem here, but not enough to presume to confidently offer a solution. It would seem desirable, though, for stix2 to work out of the box with siunitx; are there ways that stix2.sty can avoid forcing the T1 encoding, in certain circumstances, such as when testing the TeX engine shows XeTeX or LuaTeX?

[khaledhosny]

You should use unicode-math package with the OpenType STIX Two fonts, the stix2 package is for legacy non-unicode TeX engines.

[nxg]

@khaledhosny And as the author of the stix2 package, and a contributor to unicode-math, your words carry much weight.

Thanks for your comment; I'll make the appropriate changes in my own packages at the next appropriate opportunity.

It looks like this issue can be closed, therefore, but partly for my own understanding, and partly for the sake of others who may come across this issue later, can you explain what you're referring to as ‘legacy non-unicode TeX engines’? My understanding was that stix2 was for XeTeX and LuaTeX only, and never supported pdfTeX before its input became UTF-8 by default, which is what I'd have thought the phrase ‘legacy non-unicode TeX engines’ referred to. So I think I'm confused: what are the remaining engines that stix2 is still targeted at?

[khaledhosny]

From the stix2 package documentation:

The stix2 package provides minimal support for using the STIX Two fonts with versions of TeX that are limited to TFM files, Type 1 PostScript fonts, and 8-bit font encodings.

The STIX Two OpenType fonts are for Unicode TeX engines, but the stix2 package is for legacy ones. To use the OpenType fonts you need unicode-math package, and there is no STIX-specific package for them.

[nxg]

Good heavens! It appears I've been using the wrong package for years, according to sentence one of paragraph two of the introduction. I'm normally quite good about Reading The Instructions, but in this case seem to have jumped straight to the Usage section.

I have some rewriting to do....

Thanks for your discreet civility in the way you've pointed this out.