Further questions about mathrm and operatorname: spacing after colon












14














EDIT: As clarified in the answers below, this appears to be a bug with amsmath and colon and thus doesn't really have anything to do with mathrm versus operatorname.



This question contains an enlightening discussion between using mathrm and operatorname. The tl;dr version is: whenever you have an operator, use operatorname.



However it seems bad to use operatorname if what you are defining is a set, since in general operatorname adds a little space before it. This means that an expression like:



f colon operatorname{End}(V) to mathbb{R}


renders badly, as there is too much white space between the colon and the operatorname{End}. Using mathrm (the RHS) is more visually appealing:
operatorname vs mathrm



Thus if one views operatorname{End}(V) as a set, then it makes more sense to write mathrm{End}(V).



Now one can view operatorname{End} also a functor on the category of vector spaces, for instance, then you would want the operatorname:
End as a functor



My question is this: What is the best practice when dealing with a quantity that is used both as a set and an operator? Should one really switch between mathrm and operatorname as appropriate? Or is there a better option.










share|improve this question




















  • 2




    IMHO, this looks like a bug in the (re)definition of colon made by the amsmath package. Edit: Oh, by the way, welcome to TeX.SX! (:-)
    – GuM
    Nov 24 at 10:55












  • Please say exactly which packages you are using. With just amsopn there is no difference in the output
    – Andrew Swann
    Nov 24 at 10:57






  • 2




    See github.com/latex3/latex2e/issues/91 for discussion of the bug.
    – egreg
    Nov 24 at 13:44
















14














EDIT: As clarified in the answers below, this appears to be a bug with amsmath and colon and thus doesn't really have anything to do with mathrm versus operatorname.



This question contains an enlightening discussion between using mathrm and operatorname. The tl;dr version is: whenever you have an operator, use operatorname.



However it seems bad to use operatorname if what you are defining is a set, since in general operatorname adds a little space before it. This means that an expression like:



f colon operatorname{End}(V) to mathbb{R}


renders badly, as there is too much white space between the colon and the operatorname{End}. Using mathrm (the RHS) is more visually appealing:
operatorname vs mathrm



Thus if one views operatorname{End}(V) as a set, then it makes more sense to write mathrm{End}(V).



Now one can view operatorname{End} also a functor on the category of vector spaces, for instance, then you would want the operatorname:
End as a functor



My question is this: What is the best practice when dealing with a quantity that is used both as a set and an operator? Should one really switch between mathrm and operatorname as appropriate? Or is there a better option.










share|improve this question




















  • 2




    IMHO, this looks like a bug in the (re)definition of colon made by the amsmath package. Edit: Oh, by the way, welcome to TeX.SX! (:-)
    – GuM
    Nov 24 at 10:55












  • Please say exactly which packages you are using. With just amsopn there is no difference in the output
    – Andrew Swann
    Nov 24 at 10:57






  • 2




    See github.com/latex3/latex2e/issues/91 for discussion of the bug.
    – egreg
    Nov 24 at 13:44














14












14








14


1





EDIT: As clarified in the answers below, this appears to be a bug with amsmath and colon and thus doesn't really have anything to do with mathrm versus operatorname.



This question contains an enlightening discussion between using mathrm and operatorname. The tl;dr version is: whenever you have an operator, use operatorname.



However it seems bad to use operatorname if what you are defining is a set, since in general operatorname adds a little space before it. This means that an expression like:



f colon operatorname{End}(V) to mathbb{R}


renders badly, as there is too much white space between the colon and the operatorname{End}. Using mathrm (the RHS) is more visually appealing:
operatorname vs mathrm



Thus if one views operatorname{End}(V) as a set, then it makes more sense to write mathrm{End}(V).



Now one can view operatorname{End} also a functor on the category of vector spaces, for instance, then you would want the operatorname:
End as a functor



My question is this: What is the best practice when dealing with a quantity that is used both as a set and an operator? Should one really switch between mathrm and operatorname as appropriate? Or is there a better option.










share|improve this question















EDIT: As clarified in the answers below, this appears to be a bug with amsmath and colon and thus doesn't really have anything to do with mathrm versus operatorname.



This question contains an enlightening discussion between using mathrm and operatorname. The tl;dr version is: whenever you have an operator, use operatorname.



However it seems bad to use operatorname if what you are defining is a set, since in general operatorname adds a little space before it. This means that an expression like:



f colon operatorname{End}(V) to mathbb{R}


renders badly, as there is too much white space between the colon and the operatorname{End}. Using mathrm (the RHS) is more visually appealing:
operatorname vs mathrm



Thus if one views operatorname{End}(V) as a set, then it makes more sense to write mathrm{End}(V).



Now one can view operatorname{End} also a functor on the category of vector spaces, for instance, then you would want the operatorname:
End as a functor



My question is this: What is the best practice when dealing with a quantity that is used both as a set and an operator? Should one really switch between mathrm and operatorname as appropriate? Or is there a better option.







math-operators






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 24 at 14:44

























asked Nov 24 at 10:22









Howard

735




735








  • 2




    IMHO, this looks like a bug in the (re)definition of colon made by the amsmath package. Edit: Oh, by the way, welcome to TeX.SX! (:-)
    – GuM
    Nov 24 at 10:55












  • Please say exactly which packages you are using. With just amsopn there is no difference in the output
    – Andrew Swann
    Nov 24 at 10:57






  • 2




    See github.com/latex3/latex2e/issues/91 for discussion of the bug.
    – egreg
    Nov 24 at 13:44














  • 2




    IMHO, this looks like a bug in the (re)definition of colon made by the amsmath package. Edit: Oh, by the way, welcome to TeX.SX! (:-)
    – GuM
    Nov 24 at 10:55












  • Please say exactly which packages you are using. With just amsopn there is no difference in the output
    – Andrew Swann
    Nov 24 at 10:57






  • 2




    See github.com/latex3/latex2e/issues/91 for discussion of the bug.
    – egreg
    Nov 24 at 13:44








2




2




IMHO, this looks like a bug in the (re)definition of colon made by the amsmath package. Edit: Oh, by the way, welcome to TeX.SX! (:-)
– GuM
Nov 24 at 10:55






IMHO, this looks like a bug in the (re)definition of colon made by the amsmath package. Edit: Oh, by the way, welcome to TeX.SX! (:-)
– GuM
Nov 24 at 10:55














Please say exactly which packages you are using. With just amsopn there is no difference in the output
– Andrew Swann
Nov 24 at 10:57




Please say exactly which packages you are using. With just amsopn there is no difference in the output
– Andrew Swann
Nov 24 at 10:57




2




2




See github.com/latex3/latex2e/issues/91 for discussion of the bug.
– egreg
Nov 24 at 13:44




See github.com/latex3/latex2e/issues/91 for discussion of the bug.
– egreg
Nov 24 at 13:44










1 Answer
1






active

oldest

votes


















13














That's a very interesting observation.



The definition of colon in amsmath is



renewcommand{colon}{
nobreak
mskip 2mu
mathpunct{}
nonscript
mkern-thinmuskip
{:}
mskip 6mu plus 1murelax
}


(edited to show the various parts). The space you see is a consequence of the fact that colon ends with an ordinary atom, namely {:}.



It would have been better to use mathopen, as the following test shows. I first get an alias of colon and patch it to change {:} into mathopen:.



documentclass{article}
usepackage{amsmath}
usepackage{etoolbox}

letpcoloncolon
patchcmd{pcolon}{{:}}{mathopen:}{}{}

begin{document}

$f colon operatorname{End}(V) to R$

$f pcolon operatorname{End}(V) to R$

bigskip

begin{tabular}{@{}*{8}{l}@{}}
&0&1&2&3&4&5&6 \
verb|colon| &
$colon A$ &
$colon max$ &
$colon +$ &
$colon sim$ &
$colon ($ &
$colon )$ &
$colon ,$
\
verb|pcolon| &
$pcolon A$ &
$pcolon max$ &
$pcolon +$ &
$pcolon sim$ &
$pcolon ($ &
$pcolon )$ &
$pcolon ,$
end{tabular}

end{document}


In the tests, colon is followed by a symbol in each class.



enter image description here



The only noticeable differences are in the cases when colon is followed by atoms of class 1 (operators) and 3 (relations), performing perhaps better in both.



If you want to follow this suggestion, your document can load etoolbox and do



patchcmd{colon}{{:}}{mathopen:}{}{}


I don't think that it's possible to fix amsmath as many existing documents depend on it and such a change would affect the output and line breaks. It might be possible to add an option for using a fixed definition.






share|improve this answer























  • Exactly what I meant! (+1) But why not replace : with mathpunct: and compensate for the excess space in the final mskip?
    – GuM
    Nov 24 at 11:13










  • @GuM That could be another idea. I wanted to do minimal changes.
    – egreg
    Nov 24 at 11:14












  • @GuM The original definition has mathpunct{}nonscript-thinmuskip, which adds thinmuskip in scriptstyle/scriptscriptstyle. Using mathpunct: would need more computations.
    – egreg
    Nov 24 at 11:22










  • Forget about my comment: looking at the table on p. 170, a Punct atom is always followed by “(1)” glue; so, using mathpunct:nonscriptmskip-thinmuskip as the replacement code, which is what I was suggesting, amounts to having “(0)” glue after the colon, irrespective of the kind of atom that follows; which is precisely what mathopen: does! (:-)
    – GuM
    Nov 24 at 11:37










  • any ideas on whether we should do that (and option names if we do)? perhaps best as a gh issue so any change can point to that discussion/
    – David Carlisle
    Nov 24 at 12:23













Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "85"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f461537%2ffurther-questions-about-mathrm-and-operatorname-spacing-after-colon%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









13














That's a very interesting observation.



The definition of colon in amsmath is



renewcommand{colon}{
nobreak
mskip 2mu
mathpunct{}
nonscript
mkern-thinmuskip
{:}
mskip 6mu plus 1murelax
}


(edited to show the various parts). The space you see is a consequence of the fact that colon ends with an ordinary atom, namely {:}.



It would have been better to use mathopen, as the following test shows. I first get an alias of colon and patch it to change {:} into mathopen:.



documentclass{article}
usepackage{amsmath}
usepackage{etoolbox}

letpcoloncolon
patchcmd{pcolon}{{:}}{mathopen:}{}{}

begin{document}

$f colon operatorname{End}(V) to R$

$f pcolon operatorname{End}(V) to R$

bigskip

begin{tabular}{@{}*{8}{l}@{}}
&0&1&2&3&4&5&6 \
verb|colon| &
$colon A$ &
$colon max$ &
$colon +$ &
$colon sim$ &
$colon ($ &
$colon )$ &
$colon ,$
\
verb|pcolon| &
$pcolon A$ &
$pcolon max$ &
$pcolon +$ &
$pcolon sim$ &
$pcolon ($ &
$pcolon )$ &
$pcolon ,$
end{tabular}

end{document}


In the tests, colon is followed by a symbol in each class.



enter image description here



The only noticeable differences are in the cases when colon is followed by atoms of class 1 (operators) and 3 (relations), performing perhaps better in both.



If you want to follow this suggestion, your document can load etoolbox and do



patchcmd{colon}{{:}}{mathopen:}{}{}


I don't think that it's possible to fix amsmath as many existing documents depend on it and such a change would affect the output and line breaks. It might be possible to add an option for using a fixed definition.






share|improve this answer























  • Exactly what I meant! (+1) But why not replace : with mathpunct: and compensate for the excess space in the final mskip?
    – GuM
    Nov 24 at 11:13










  • @GuM That could be another idea. I wanted to do minimal changes.
    – egreg
    Nov 24 at 11:14












  • @GuM The original definition has mathpunct{}nonscript-thinmuskip, which adds thinmuskip in scriptstyle/scriptscriptstyle. Using mathpunct: would need more computations.
    – egreg
    Nov 24 at 11:22










  • Forget about my comment: looking at the table on p. 170, a Punct atom is always followed by “(1)” glue; so, using mathpunct:nonscriptmskip-thinmuskip as the replacement code, which is what I was suggesting, amounts to having “(0)” glue after the colon, irrespective of the kind of atom that follows; which is precisely what mathopen: does! (:-)
    – GuM
    Nov 24 at 11:37










  • any ideas on whether we should do that (and option names if we do)? perhaps best as a gh issue so any change can point to that discussion/
    – David Carlisle
    Nov 24 at 12:23


















13














That's a very interesting observation.



The definition of colon in amsmath is



renewcommand{colon}{
nobreak
mskip 2mu
mathpunct{}
nonscript
mkern-thinmuskip
{:}
mskip 6mu plus 1murelax
}


(edited to show the various parts). The space you see is a consequence of the fact that colon ends with an ordinary atom, namely {:}.



It would have been better to use mathopen, as the following test shows. I first get an alias of colon and patch it to change {:} into mathopen:.



documentclass{article}
usepackage{amsmath}
usepackage{etoolbox}

letpcoloncolon
patchcmd{pcolon}{{:}}{mathopen:}{}{}

begin{document}

$f colon operatorname{End}(V) to R$

$f pcolon operatorname{End}(V) to R$

bigskip

begin{tabular}{@{}*{8}{l}@{}}
&0&1&2&3&4&5&6 \
verb|colon| &
$colon A$ &
$colon max$ &
$colon +$ &
$colon sim$ &
$colon ($ &
$colon )$ &
$colon ,$
\
verb|pcolon| &
$pcolon A$ &
$pcolon max$ &
$pcolon +$ &
$pcolon sim$ &
$pcolon ($ &
$pcolon )$ &
$pcolon ,$
end{tabular}

end{document}


In the tests, colon is followed by a symbol in each class.



enter image description here



The only noticeable differences are in the cases when colon is followed by atoms of class 1 (operators) and 3 (relations), performing perhaps better in both.



If you want to follow this suggestion, your document can load etoolbox and do



patchcmd{colon}{{:}}{mathopen:}{}{}


I don't think that it's possible to fix amsmath as many existing documents depend on it and such a change would affect the output and line breaks. It might be possible to add an option for using a fixed definition.






share|improve this answer























  • Exactly what I meant! (+1) But why not replace : with mathpunct: and compensate for the excess space in the final mskip?
    – GuM
    Nov 24 at 11:13










  • @GuM That could be another idea. I wanted to do minimal changes.
    – egreg
    Nov 24 at 11:14












  • @GuM The original definition has mathpunct{}nonscript-thinmuskip, which adds thinmuskip in scriptstyle/scriptscriptstyle. Using mathpunct: would need more computations.
    – egreg
    Nov 24 at 11:22










  • Forget about my comment: looking at the table on p. 170, a Punct atom is always followed by “(1)” glue; so, using mathpunct:nonscriptmskip-thinmuskip as the replacement code, which is what I was suggesting, amounts to having “(0)” glue after the colon, irrespective of the kind of atom that follows; which is precisely what mathopen: does! (:-)
    – GuM
    Nov 24 at 11:37










  • any ideas on whether we should do that (and option names if we do)? perhaps best as a gh issue so any change can point to that discussion/
    – David Carlisle
    Nov 24 at 12:23
















13












13








13






That's a very interesting observation.



The definition of colon in amsmath is



renewcommand{colon}{
nobreak
mskip 2mu
mathpunct{}
nonscript
mkern-thinmuskip
{:}
mskip 6mu plus 1murelax
}


(edited to show the various parts). The space you see is a consequence of the fact that colon ends with an ordinary atom, namely {:}.



It would have been better to use mathopen, as the following test shows. I first get an alias of colon and patch it to change {:} into mathopen:.



documentclass{article}
usepackage{amsmath}
usepackage{etoolbox}

letpcoloncolon
patchcmd{pcolon}{{:}}{mathopen:}{}{}

begin{document}

$f colon operatorname{End}(V) to R$

$f pcolon operatorname{End}(V) to R$

bigskip

begin{tabular}{@{}*{8}{l}@{}}
&0&1&2&3&4&5&6 \
verb|colon| &
$colon A$ &
$colon max$ &
$colon +$ &
$colon sim$ &
$colon ($ &
$colon )$ &
$colon ,$
\
verb|pcolon| &
$pcolon A$ &
$pcolon max$ &
$pcolon +$ &
$pcolon sim$ &
$pcolon ($ &
$pcolon )$ &
$pcolon ,$
end{tabular}

end{document}


In the tests, colon is followed by a symbol in each class.



enter image description here



The only noticeable differences are in the cases when colon is followed by atoms of class 1 (operators) and 3 (relations), performing perhaps better in both.



If you want to follow this suggestion, your document can load etoolbox and do



patchcmd{colon}{{:}}{mathopen:}{}{}


I don't think that it's possible to fix amsmath as many existing documents depend on it and such a change would affect the output and line breaks. It might be possible to add an option for using a fixed definition.






share|improve this answer














That's a very interesting observation.



The definition of colon in amsmath is



renewcommand{colon}{
nobreak
mskip 2mu
mathpunct{}
nonscript
mkern-thinmuskip
{:}
mskip 6mu plus 1murelax
}


(edited to show the various parts). The space you see is a consequence of the fact that colon ends with an ordinary atom, namely {:}.



It would have been better to use mathopen, as the following test shows. I first get an alias of colon and patch it to change {:} into mathopen:.



documentclass{article}
usepackage{amsmath}
usepackage{etoolbox}

letpcoloncolon
patchcmd{pcolon}{{:}}{mathopen:}{}{}

begin{document}

$f colon operatorname{End}(V) to R$

$f pcolon operatorname{End}(V) to R$

bigskip

begin{tabular}{@{}*{8}{l}@{}}
&0&1&2&3&4&5&6 \
verb|colon| &
$colon A$ &
$colon max$ &
$colon +$ &
$colon sim$ &
$colon ($ &
$colon )$ &
$colon ,$
\
verb|pcolon| &
$pcolon A$ &
$pcolon max$ &
$pcolon +$ &
$pcolon sim$ &
$pcolon ($ &
$pcolon )$ &
$pcolon ,$
end{tabular}

end{document}


In the tests, colon is followed by a symbol in each class.



enter image description here



The only noticeable differences are in the cases when colon is followed by atoms of class 1 (operators) and 3 (relations), performing perhaps better in both.



If you want to follow this suggestion, your document can load etoolbox and do



patchcmd{colon}{{:}}{mathopen:}{}{}


I don't think that it's possible to fix amsmath as many existing documents depend on it and such a change would affect the output and line breaks. It might be possible to add an option for using a fixed definition.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 24 at 11:11

























answered Nov 24 at 11:05









egreg

706k8618783160




706k8618783160












  • Exactly what I meant! (+1) But why not replace : with mathpunct: and compensate for the excess space in the final mskip?
    – GuM
    Nov 24 at 11:13










  • @GuM That could be another idea. I wanted to do minimal changes.
    – egreg
    Nov 24 at 11:14












  • @GuM The original definition has mathpunct{}nonscript-thinmuskip, which adds thinmuskip in scriptstyle/scriptscriptstyle. Using mathpunct: would need more computations.
    – egreg
    Nov 24 at 11:22










  • Forget about my comment: looking at the table on p. 170, a Punct atom is always followed by “(1)” glue; so, using mathpunct:nonscriptmskip-thinmuskip as the replacement code, which is what I was suggesting, amounts to having “(0)” glue after the colon, irrespective of the kind of atom that follows; which is precisely what mathopen: does! (:-)
    – GuM
    Nov 24 at 11:37










  • any ideas on whether we should do that (and option names if we do)? perhaps best as a gh issue so any change can point to that discussion/
    – David Carlisle
    Nov 24 at 12:23




















  • Exactly what I meant! (+1) But why not replace : with mathpunct: and compensate for the excess space in the final mskip?
    – GuM
    Nov 24 at 11:13










  • @GuM That could be another idea. I wanted to do minimal changes.
    – egreg
    Nov 24 at 11:14












  • @GuM The original definition has mathpunct{}nonscript-thinmuskip, which adds thinmuskip in scriptstyle/scriptscriptstyle. Using mathpunct: would need more computations.
    – egreg
    Nov 24 at 11:22










  • Forget about my comment: looking at the table on p. 170, a Punct atom is always followed by “(1)” glue; so, using mathpunct:nonscriptmskip-thinmuskip as the replacement code, which is what I was suggesting, amounts to having “(0)” glue after the colon, irrespective of the kind of atom that follows; which is precisely what mathopen: does! (:-)
    – GuM
    Nov 24 at 11:37










  • any ideas on whether we should do that (and option names if we do)? perhaps best as a gh issue so any change can point to that discussion/
    – David Carlisle
    Nov 24 at 12:23


















Exactly what I meant! (+1) But why not replace : with mathpunct: and compensate for the excess space in the final mskip?
– GuM
Nov 24 at 11:13




Exactly what I meant! (+1) But why not replace : with mathpunct: and compensate for the excess space in the final mskip?
– GuM
Nov 24 at 11:13












@GuM That could be another idea. I wanted to do minimal changes.
– egreg
Nov 24 at 11:14






@GuM That could be another idea. I wanted to do minimal changes.
– egreg
Nov 24 at 11:14














@GuM The original definition has mathpunct{}nonscript-thinmuskip, which adds thinmuskip in scriptstyle/scriptscriptstyle. Using mathpunct: would need more computations.
– egreg
Nov 24 at 11:22




@GuM The original definition has mathpunct{}nonscript-thinmuskip, which adds thinmuskip in scriptstyle/scriptscriptstyle. Using mathpunct: would need more computations.
– egreg
Nov 24 at 11:22












Forget about my comment: looking at the table on p. 170, a Punct atom is always followed by “(1)” glue; so, using mathpunct:nonscriptmskip-thinmuskip as the replacement code, which is what I was suggesting, amounts to having “(0)” glue after the colon, irrespective of the kind of atom that follows; which is precisely what mathopen: does! (:-)
– GuM
Nov 24 at 11:37




Forget about my comment: looking at the table on p. 170, a Punct atom is always followed by “(1)” glue; so, using mathpunct:nonscriptmskip-thinmuskip as the replacement code, which is what I was suggesting, amounts to having “(0)” glue after the colon, irrespective of the kind of atom that follows; which is precisely what mathopen: does! (:-)
– GuM
Nov 24 at 11:37












any ideas on whether we should do that (and option names if we do)? perhaps best as a gh issue so any change can point to that discussion/
– David Carlisle
Nov 24 at 12:23






any ideas on whether we should do that (and option names if we do)? perhaps best as a gh issue so any change can point to that discussion/
– David Carlisle
Nov 24 at 12:23




















draft saved

draft discarded




















































Thanks for contributing an answer to TeX - LaTeX Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f461537%2ffurther-questions-about-mathrm-and-operatorname-spacing-after-colon%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Quarter-circle Tiles

build a pushdown automaton that recognizes the reverse language of a given pushdown automaton?

Mont Emei