Text content before number in S column causes wrong font to be used

[lblblb]

The cause of this observation is that I want to use siunitx S columns to print monospaced (tabular) numbers if needed, but use proportional numbers by default. After hours of fiddling I now have a solution that works as well as possible, by using pre- and post-code for each column specifier. To get monospaced figures, I use \ttfamily for that column (and set it back to \sffamily as post-code if needed). My font setup is such that \ttfamily is the same font as \sffamily, but fontspec makes all characters monospaced. This solution is far more robust than using \addfontfeatures{Numbers=Monospaced} instead, where it worked only half the time.

Now this approach works well until I place something before the number:

\documentclass{article}

\usepackage{array,siunitx}

\sisetup{
	detect-all=true,
	mode=text,
	table-space-text-pre = \(-\)
}

\begin{document}

\begin{tabular}{%
>{\ttfamily}S[table-format=1.3]%
}
%
0,818 \\
-0,818 \\
\(-\)0,818 \\
A0,818 \\
0,818A \\
\end{tabular}

\end{document}

I compiled with TeXLive 2017 lualatex.

• The third row has the wrong font because I have a \(-\) in front of the number. I want to use math-mode minuses to get a more uniform look in my use case. It's also weird that only this row has the comma and the alignment is off.
• The fourth row shows that the single letter is in the \ttfamily as specified, but the processed number after it is not.
• The fifth row shows that something after the number doesn't cause the problems.

I tried the MWE with braces around the "foreign" content but it didn't make a difference in output.

Here is a real-use example of the issue, where the preceeding math-mode minus sign is causing a switch back to the surrounding "proportional" \sffamily:

[josephwright]

The underlying issue here is that there are two distinct things we might want to do with 'pre-cell' material. The first is to print something: that needs space and when we are reserving space, that means using a box. The other is to apply font/colour changes: this needs to happen outside of a box. The package checks whether there is any apparent width to pre-cell material before picking the route. The issue here is you need both aspects. The obvious way to handle that is to provide an explicit key which can insert font/colour changes (i.e. zero-width material). I'm putting that down for v3.1 - code-wise it's trivial, it's more how to describe the option that's an issue.