Open jfbu opened 6 years ago
Since \rm
has been deprecated in 1994, I would not bother.
Hah! That’s a good one.
I can check it out, but as Enrico implies I don’t think I can promise a fix unless it’s reasonably straightforward.
Perhaps you can use something like the \symupswitch
command I suggested in https://github.com/wspr/unicode-math/issues/459#issuecomment-384900248. As long as only ascii chars are involved it should do what people expect from \rm:
\documentclass{article}
\usepackage{unicode-math}
\ExplSyntaxOn
\newcommand\symupswitch{\tl_set:Nn \l__um_mathstyle_tl {up}\__um_switchto_up: \__um_mathgroup_set:n {-1}}
\ExplSyntaxOff
\renewcommand\rm{\ifmmode\symupswitch\else\normalfont\rmfamily\fi}
\begin{document}
\sffamily text {\rm text}
$\symup{Abc} Abc {\rm Abc} Abc $
\end{document}
The root cause is that \@fontswitch
has kept its standard meaning but \use@mathgroup
got modified. I can propose a PR to modify \@fontswitch
so that it does what could be the correct thing vz \__um_group_begin:
and \__um_group_end:n
.
Actually there is already a \__um_fontswitch:n
used by patched \operator@font
. What is lacking is a hack of \@fontswitch
akin to that.
@jbfu — that's probably the best idea. I have half a mind to copy over the entire maths portion of the NFSS into unicode-math and start rewriting it (but not any time soon). Unfortunately won't be able to participate much over the next couple weeks, and then travelling...
Proposed patch I don't have enough experience and usage of unicode-math to test this seriously this is why I don't make PR but just propose it here in the form of a user fix in case it can be useful and incorporated in unicode-math.
\documentclass{article}
\usepackage{unicode-math}
\makeatletter
\ExplSyntaxOn
\def\@fontswitch #1#2{\ifmmode
% ORIGINAL KERNEL CODE
% \let \math@bgroup \relax
% \def \math@egroup {\let \math@bgroup \@@math@bgroup
% \let \math@egroup \@@math@egroup }%
% PROPOSED NEW CODE LIFTED FROM \__um_fontswitch:n
\cs_set_eq:NN \math@bgroup \scan_stop:
\cs_set_eq:NN \__um_group_begin: \scan_stop:
\cs_set:Npn \__um_group_end:n
{\cs_set_eq:NN \__um_group_begin: \__um_group_begin_frozen:
\cs_set_eq:NN \__um_group_end:n \__um_group_end_frozen:n
\cs_set_eq:NN \math@bgroup \__ummath@bgroup
\cs_set_eq:NN \math@egroup \__ummath@egroup }%
\cs_set_eq:NN \math@egroup \__um_group_end:n
% AGAIN ORIGINAL KERNEL CODE
#2\relax
\else
#1%
\fi
}%
\ExplSyntaxOff
\makeatother
\begin{document}
\def\ABC{ABC}
$\tracingmacros1 \mathrm{\ABC}$
\typeout{XXXXXXXXXX}
$\tracingmacros1 \rm\ABC$
\makeatletter
\typeout{XXXXXXXXXX}
$\tracingmacros1 \operator@font \ABC$
\end{document}
% Local variables:
% TeX-engine: xetex;
% End:
Added note: the two lines involving \__ummath@bgroup
and \__ummath@egroup
look suspicous because in unicode-math-code.pdf
I find \@@math@bgroup
used only once, in the definition of \@@_fontswitch:n
, and it never gets a definition, same for \@@math@egroup
. Is this some kind of typo?
ah I see of course! The unicode-math sources copied over \@@math@bgroup
from LaTeX kernel but the @@
got transformed... This is a bug...
It looks good to me, thanks. Note that \@@math@bgroup and \@@math@egroup are the “frozen” versions of \@math@bgroup and \@math@bgroup as defined in the kernel — they’re just reseting the definitions back to how they “should be”.
So naturally, my user hack should read
\makeatletter
\ExplSyntaxOn
\def\@fontswitch #1#2{\ifmmode
% ORIGINAL KERNEL CODE
% \let \math@bgroup \relax
% \def \math@egroup {\let \math@bgroup \@@math@bgroup
% \let \math@egroup \@@math@egroup }%
% PROPOSED NEW CODE LIFTED FROM \__um_fontswitch:n
\cs_set_eq:NN \math@bgroup \scan_stop:
\cs_set_eq:NN \__um_group_begin: \scan_stop:
\cs_set:Npn \__um_group_end:n
{\cs_set_eq:NN \__um_group_begin: \__um_group_begin_frozen:
\cs_set_eq:NN \__um_group_end:n \__um_group_end_frozen:n
\cs_set_eq:NN \math@bgroup \@@math@bgroup
\cs_set_eq:NN \math@egroup \@@math@egroup }%
\cs_set_eq:NN \math@egroup \__um_group_end:n
% AGAIN ORIGINAL KERNEL CODE
#2\relax
\else
#1%
\fi
}%
\ExplSyntaxOff
\makeatother
and the current \__um_fontswitch:n
is buggy.
Sorry for spam but only to add to passers-by that there is a difference between the \__um_group_begin_frozen:
and \__um_group_end_frozen:n
with meanings respectively
\begingroup
\protected\long macro:#1->#1\group_end:
and the LaTeX kernel \@@math@bgroup
and \@@math@egroup
which have meanings
\@@math@bgroup:
begin-group character {
\@@math@egroup:
macro:#1->#1\egroup
so the @@
problem can (perhaps, but after all if the original kernel version are never used it does not matter so much) now simply be circumvented by using the former for the latter in the sources. But I presume LaTeX3 docstrip has a way to make possible inserting \@@math@bgroup
in source code without the @@
being transformed?
arggh,
now simply be circumvented
I meant NOT simply be circumvented.
@jbfu — embarrassing indeed for me to have a typo like that. In a l3docstrip file you can write \@@@@math@bgroup
to result in \@@math@bgroup
in the .sty file.
The differences that you see there are to overcome the spacing difference you get with something surrounded by {} in math mode. The side-effect of this change was that _\symup{foo}
is no longer valid syntax, something none of us are really unhappy with.
In a l3docstrip file you can write
\@@@@math@bgroup
to result in\@@math@bgroup
in the .sty file.
I trusted you guys had foreseen every possibility :)
The differences that you see there are to overcome the spacing difference you get with something surrounded by {} in math mode. The side-effect of this change was that
_\symup{foo}
is no longer valid syntax, something none of us are really unhappy with.
Ok, the code comments in source2e.pdf are bit hard to follow with a first version of \select@group
entirely commented out, and some apparent mix up in comments of \use@mathgroup
about macro parameters, references to a "margid option" which probably refers to some earlier code, and this about \math@bgroup/\math@egroup
:
We use
\bgroup instead of \begingroup to avoid `leaking out' of style changes. This has
the side effect of always producing mathord atoms.
whose second sentence is clear, but I don't understand the meaning of the first sentence. Elsewhere the code comments explicitely states braces allow the usage you mentioned, and I agree this syntax was too lax for a macro system which replaced \over
by \frac
. Fortunately I never became aware one could do that so I would not lament its passing.
ah sorry I see now what style changes
meant. It refers exactly to the usage as _\mathrm{foo}
with style
referring to \scriptstyle
. Well, seems I do need to spam before understanding something!
Hmm... not sure I understood right. Anyway, that's off-topic, so will stop here.
Oh, good stuff! I had also never fully understood that comment but didn't think to ask :)
Description
$\rm AB$
has changed behaviour with0.8l
release. I see no trace in CHANGES.md or PDF documentation.Check/indicate
Minimal example demonstrating the issue
produces
both with xelatex and lualatex.
Further details
The first "bad" commit is 0f245c2ec4c527397a67f3ff04aea8107a6cbe31