Alignment of implication arrows with text on top
My proofs often look like this:
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&stackrel{text{Explanation}}{implies}text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies} text{Fourth Statement}
end{align}
end{document}

And the issue is that the alignment takes into account the entire stackrel, while I want it to algin with the implication arrow.
I tried stackrel{Explanation}{&implies} but that throws an error.
mathclap works, if the explanation is not too long and doesn't touch the statement after the implication arrow.
Do you have any suggestions how to solve this problem?
formatting align
add a comment |
My proofs often look like this:
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&stackrel{text{Explanation}}{implies}text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies} text{Fourth Statement}
end{align}
end{document}

And the issue is that the alignment takes into account the entire stackrel, while I want it to algin with the implication arrow.
I tried stackrel{Explanation}{&implies} but that throws an error.
mathclap works, if the explanation is not too long and doesn't touch the statement after the implication arrow.
Do you have any suggestions how to solve this problem?
formatting align
Can you add a full compilable code, please? For example I have not understood your question.
– Sebastiano
Dec 29 '18 at 13:22
@Sebastiano like this?
– Felix B.
Dec 29 '18 at 13:27
Ok :-)Thank you very much.
– Sebastiano
Dec 29 '18 at 13:28
1
i see no reason that using aphantomwon't work. for the first statement, use thephantomwith the whole content of thestackrelwith the longest text. for the second, use thephantomfor just the top element of thestackrel. some adjustment will be necessary if two "printed" explanations" have different widths. i can't test this now since i don't have tex installed on my laptop.
– barbara beeton
Dec 30 '18 at 0:25
add a comment |
My proofs often look like this:
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&stackrel{text{Explanation}}{implies}text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies} text{Fourth Statement}
end{align}
end{document}

And the issue is that the alignment takes into account the entire stackrel, while I want it to algin with the implication arrow.
I tried stackrel{Explanation}{&implies} but that throws an error.
mathclap works, if the explanation is not too long and doesn't touch the statement after the implication arrow.
Do you have any suggestions how to solve this problem?
formatting align
My proofs often look like this:
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&stackrel{text{Explanation}}{implies}text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies} text{Fourth Statement}
end{align}
end{document}

And the issue is that the alignment takes into account the entire stackrel, while I want it to algin with the implication arrow.
I tried stackrel{Explanation}{&implies} but that throws an error.
mathclap works, if the explanation is not too long and doesn't touch the statement after the implication arrow.
Do you have any suggestions how to solve this problem?
formatting align
formatting align
edited Dec 30 '18 at 13:10
asked Dec 29 '18 at 13:17
Felix B.
1458
1458
Can you add a full compilable code, please? For example I have not understood your question.
– Sebastiano
Dec 29 '18 at 13:22
@Sebastiano like this?
– Felix B.
Dec 29 '18 at 13:27
Ok :-)Thank you very much.
– Sebastiano
Dec 29 '18 at 13:28
1
i see no reason that using aphantomwon't work. for the first statement, use thephantomwith the whole content of thestackrelwith the longest text. for the second, use thephantomfor just the top element of thestackrel. some adjustment will be necessary if two "printed" explanations" have different widths. i can't test this now since i don't have tex installed on my laptop.
– barbara beeton
Dec 30 '18 at 0:25
add a comment |
Can you add a full compilable code, please? For example I have not understood your question.
– Sebastiano
Dec 29 '18 at 13:22
@Sebastiano like this?
– Felix B.
Dec 29 '18 at 13:27
Ok :-)Thank you very much.
– Sebastiano
Dec 29 '18 at 13:28
1
i see no reason that using aphantomwon't work. for the first statement, use thephantomwith the whole content of thestackrelwith the longest text. for the second, use thephantomfor just the top element of thestackrel. some adjustment will be necessary if two "printed" explanations" have different widths. i can't test this now since i don't have tex installed on my laptop.
– barbara beeton
Dec 30 '18 at 0:25
Can you add a full compilable code, please? For example I have not understood your question.
– Sebastiano
Dec 29 '18 at 13:22
Can you add a full compilable code, please? For example I have not understood your question.
– Sebastiano
Dec 29 '18 at 13:22
@Sebastiano like this?
– Felix B.
Dec 29 '18 at 13:27
@Sebastiano like this?
– Felix B.
Dec 29 '18 at 13:27
Ok :-)Thank you very much.
– Sebastiano
Dec 29 '18 at 13:28
Ok :-)Thank you very much.
– Sebastiano
Dec 29 '18 at 13:28
1
1
i see no reason that using a
phantom won't work. for the first statement, use the phantom with the whole content of the stackrel with the longest text. for the second, use the phantom for just the top element of the stackrel. some adjustment will be necessary if two "printed" explanations" have different widths. i can't test this now since i don't have tex installed on my laptop.– barbara beeton
Dec 30 '18 at 0:25
i see no reason that using a
phantom won't work. for the first statement, use the phantom with the whole content of the stackrel with the longest text. for the second, use the phantom for just the top element of the stackrel. some adjustment will be necessary if two "printed" explanations" have different widths. i can't test this now since i don't have tex installed on my laptop.– barbara beeton
Dec 30 '18 at 0:25
add a comment |
3 Answers
3
active
oldest
votes
The stackrel command is defined as
#1#2 → mathrel{mathop{#2}limits^{#1}}
so you could use smashoperator from the mathtools package to get rid of the space introduced by the left half of the superscript.
I'm defining smashstackrel below, a version of stackrel that incorporates smashoperator. I think smashstackrel[l] does precisely what you want.
I also defined feliximplies{<text>} to make life simpler.
documentclass{article}
usepackage{mathtools}
newcommand*smashstackrel[3][lr]{%
mathrel{smashoperator[#1]{mathop{#3}^{#2}}}
}
newcommand*feliximplies[1]{smashstackrel[l]{textnormal{#1}}{implies}}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&smashstackrel[l]{text{Explanation}}{implies}text{Third Statement}\
&feliximplies{Explanation} text{Fourth Statement}
end{align}
end{document}

Notes:
The optional argument of
smashstackrelcan be either[l],[r]or[lr]depending on whether you want to ignore the left side or the right side or both sides of the superscript for spacing purposes.
impliesis defined asDOTSB;Longrightarrow;and;produces a space that can be stretched (but not shrunk, by default).
This space will no longer be stretchable ifstackrel(orsmashstackrel) is used, so doing so feels slightly dubious.
I think something like
;mkern-thickmuskipstackrel{<text>}{implies};mkern-thickmuskip
might be more appropriate than just
stackrel{<text>}{implies}. This reinserts precisely the amount of stretchability that was lost. (The same remark applies tosmashstackrelandnoLstackrel, which is defined below.)
In this case it doesn't matter though, since here the space won't be stretched anyway. It would matter if this command were used inline rather than in a display environment.
Brief explanation:
;is defined asmskipthickmuskipand inserts a horizontal space of lengththickmuskip, which by default is5mubut can be stretched to10muif necessary.mkernis similar tomskip, but it doesn't allow for stretching. Somkern-thickmuskipremoves a horizontal space of5muin this case so that we end up with a horizontal space of0muthat can be stretched to up to5mu. See this answer for more information on spacing commands.
A possible disadvantage of
smashstackrelcompared tostackrelis that it always typesets things indisplaystyle.
I've included a version ofsmashstackrel[l]that doesn't do this below because I had already written it before I suddenly remembered the existence ofsmashoperator.
makeatletter %% <- make @ usable in command names
newcommand*noLstackrel[2]{mathpalettenoLstackrel@{{#1}{#2}}}
newcommand*noLstackrel@[2]{noLstackrel@@{#1}#2}
newcommand*noLstackrel@@[3]{% #1 = displaystyle etc., #2 = top, #3 = bottom
begingroup %% <- limit scope of boxes
sbox0{$m@th#1stackrel{#2}{#3}$}% %% <- put stackrel construction in box 0
sbox2{$m@th#1#3$}% %% <- put base symbol in box 2
hskip.5wd2 hskip-.5wd0 %% <- remove excess width on the left
mathrel{usebox0}% %% <- print box 0
endgroup
}
makeatother %% <- revert @
Usage:
noLstackrel{<stuff on top>}{implies}.
Excellent your work and the same of @caverac.
– Sebastiano
Dec 30 '18 at 10:16
The second note is a bit hard to read because you only define the command you refer to, in the third note. Probably because you have rewritten the answer? Otherwise excellent answer. Do you think it would be a good idea to redefineimpliesin a way that it allowsimplies^{Explanation}?
– Felix B.
Dec 30 '18 at 11:23
1
@FelixB. Oops, that is indeed what happened. What you suggest sounds like a neat idea, but it seems like it'd be a bit finicky to implement if you wantimpliesto still be treated as a relation (rather than an operator) for spacing purposes and even more so if you want the left side to be "smashed" as above. Becausemathop{Longrightarrow}does neither of these things, you would have to use something like@ifnextcharto look ahead for an explicit^.
– Circumscribe
Dec 30 '18 at 11:55
If you say it might be finicky I probably better leave my hands off of it. Still trying to wrap my head around what all the commands in the second note do. And I haven't really understood the third comment (I think I know that the problem is that it treats sums limits different in()than[]but I don't understand the solution) Wouldn't usinglimitslike in the originalstackrelsolve this problem?
– Felix B.
Dec 30 '18 at 11:58
1
I've added a brief explanation to second remark. It only really matters for inline ($…$) equations though, since I don't think spaces in display environments are really ever stretched.
– Circumscribe
Dec 30 '18 at 12:18
|
show 2 more comments
You could try eqnarray
begin{eqnarray}
&& text{First Statement}\
&implies& text{Second Statement}\
&stackrel{text{Explanation}}{implies}&text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies}& text{Fourth Statement}
end{eqnarray}

2
tex.stackexchange.com/questions/196/eqnarray-vs-align judging from the most popular answer that might not be the best idea?
– Felix B.
Dec 29 '18 at 13:46
@FelixB. You are absolutely right! I will leave it here until someone else gives you a better solution
– caverac
Dec 29 '18 at 14:03
add a comment |
Reading the documentation on mathtools after learning about smashoperators from Circumscribes answer, I found another possible solution: xRightarrow
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{Statement}\
&implies text{implies arrow}\
&xRightarrow{text{Explanation}}text{xRightarrow}\
&xRightarrow{(*)} text{xRightarrow}\
&;xRightarrow{(*)}; text{xRightarrow with ;}\
&implies text{implies arrow}\
&;xRightarrow{}; text{xRightarrow with ;}\
&;Rightarrow; text{Rightarrow with ;}
end{align}
end{document}
Resulting in:

The advantage of this solution is, that it utilizes a command from a known package, which probably has less errors than a home cooked solution. And it allows for underscript too.
The disadvantage is probably clear from the picture. implies inserts a space before the arrow, which xRightarrow does not do.
(EDIT: this can be fixed with ; at the sides as Circumscribes points out but it is still noticeable that xRightarrow is based on Rightarrow, as you can see from the default length when there is no input)
So instead of implies you would probably have to use Rightarrow instead. Secondly I am not sure if I visually prefer different length arrows over explanations which overflow the width of the usual implies arrow.
Seems like a good solution. To make the spacing match that ofimpliesyou should use;xRightarrow{…};, sinceimpliesis effectively the same thing as;Longrightarrow;.
– Circumscribe
Dec 30 '18 at 14:15
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f467779%2falignment-of-implication-arrows-with-text-on-top%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
The stackrel command is defined as
#1#2 → mathrel{mathop{#2}limits^{#1}}
so you could use smashoperator from the mathtools package to get rid of the space introduced by the left half of the superscript.
I'm defining smashstackrel below, a version of stackrel that incorporates smashoperator. I think smashstackrel[l] does precisely what you want.
I also defined feliximplies{<text>} to make life simpler.
documentclass{article}
usepackage{mathtools}
newcommand*smashstackrel[3][lr]{%
mathrel{smashoperator[#1]{mathop{#3}^{#2}}}
}
newcommand*feliximplies[1]{smashstackrel[l]{textnormal{#1}}{implies}}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&smashstackrel[l]{text{Explanation}}{implies}text{Third Statement}\
&feliximplies{Explanation} text{Fourth Statement}
end{align}
end{document}

Notes:
The optional argument of
smashstackrelcan be either[l],[r]or[lr]depending on whether you want to ignore the left side or the right side or both sides of the superscript for spacing purposes.
impliesis defined asDOTSB;Longrightarrow;and;produces a space that can be stretched (but not shrunk, by default).
This space will no longer be stretchable ifstackrel(orsmashstackrel) is used, so doing so feels slightly dubious.
I think something like
;mkern-thickmuskipstackrel{<text>}{implies};mkern-thickmuskip
might be more appropriate than just
stackrel{<text>}{implies}. This reinserts precisely the amount of stretchability that was lost. (The same remark applies tosmashstackrelandnoLstackrel, which is defined below.)
In this case it doesn't matter though, since here the space won't be stretched anyway. It would matter if this command were used inline rather than in a display environment.
Brief explanation:
;is defined asmskipthickmuskipand inserts a horizontal space of lengththickmuskip, which by default is5mubut can be stretched to10muif necessary.mkernis similar tomskip, but it doesn't allow for stretching. Somkern-thickmuskipremoves a horizontal space of5muin this case so that we end up with a horizontal space of0muthat can be stretched to up to5mu. See this answer for more information on spacing commands.
A possible disadvantage of
smashstackrelcompared tostackrelis that it always typesets things indisplaystyle.
I've included a version ofsmashstackrel[l]that doesn't do this below because I had already written it before I suddenly remembered the existence ofsmashoperator.
makeatletter %% <- make @ usable in command names
newcommand*noLstackrel[2]{mathpalettenoLstackrel@{{#1}{#2}}}
newcommand*noLstackrel@[2]{noLstackrel@@{#1}#2}
newcommand*noLstackrel@@[3]{% #1 = displaystyle etc., #2 = top, #3 = bottom
begingroup %% <- limit scope of boxes
sbox0{$m@th#1stackrel{#2}{#3}$}% %% <- put stackrel construction in box 0
sbox2{$m@th#1#3$}% %% <- put base symbol in box 2
hskip.5wd2 hskip-.5wd0 %% <- remove excess width on the left
mathrel{usebox0}% %% <- print box 0
endgroup
}
makeatother %% <- revert @
Usage:
noLstackrel{<stuff on top>}{implies}.
Excellent your work and the same of @caverac.
– Sebastiano
Dec 30 '18 at 10:16
The second note is a bit hard to read because you only define the command you refer to, in the third note. Probably because you have rewritten the answer? Otherwise excellent answer. Do you think it would be a good idea to redefineimpliesin a way that it allowsimplies^{Explanation}?
– Felix B.
Dec 30 '18 at 11:23
1
@FelixB. Oops, that is indeed what happened. What you suggest sounds like a neat idea, but it seems like it'd be a bit finicky to implement if you wantimpliesto still be treated as a relation (rather than an operator) for spacing purposes and even more so if you want the left side to be "smashed" as above. Becausemathop{Longrightarrow}does neither of these things, you would have to use something like@ifnextcharto look ahead for an explicit^.
– Circumscribe
Dec 30 '18 at 11:55
If you say it might be finicky I probably better leave my hands off of it. Still trying to wrap my head around what all the commands in the second note do. And I haven't really understood the third comment (I think I know that the problem is that it treats sums limits different in()than[]but I don't understand the solution) Wouldn't usinglimitslike in the originalstackrelsolve this problem?
– Felix B.
Dec 30 '18 at 11:58
1
I've added a brief explanation to second remark. It only really matters for inline ($…$) equations though, since I don't think spaces in display environments are really ever stretched.
– Circumscribe
Dec 30 '18 at 12:18
|
show 2 more comments
The stackrel command is defined as
#1#2 → mathrel{mathop{#2}limits^{#1}}
so you could use smashoperator from the mathtools package to get rid of the space introduced by the left half of the superscript.
I'm defining smashstackrel below, a version of stackrel that incorporates smashoperator. I think smashstackrel[l] does precisely what you want.
I also defined feliximplies{<text>} to make life simpler.
documentclass{article}
usepackage{mathtools}
newcommand*smashstackrel[3][lr]{%
mathrel{smashoperator[#1]{mathop{#3}^{#2}}}
}
newcommand*feliximplies[1]{smashstackrel[l]{textnormal{#1}}{implies}}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&smashstackrel[l]{text{Explanation}}{implies}text{Third Statement}\
&feliximplies{Explanation} text{Fourth Statement}
end{align}
end{document}

Notes:
The optional argument of
smashstackrelcan be either[l],[r]or[lr]depending on whether you want to ignore the left side or the right side or both sides of the superscript for spacing purposes.
impliesis defined asDOTSB;Longrightarrow;and;produces a space that can be stretched (but not shrunk, by default).
This space will no longer be stretchable ifstackrel(orsmashstackrel) is used, so doing so feels slightly dubious.
I think something like
;mkern-thickmuskipstackrel{<text>}{implies};mkern-thickmuskip
might be more appropriate than just
stackrel{<text>}{implies}. This reinserts precisely the amount of stretchability that was lost. (The same remark applies tosmashstackrelandnoLstackrel, which is defined below.)
In this case it doesn't matter though, since here the space won't be stretched anyway. It would matter if this command were used inline rather than in a display environment.
Brief explanation:
;is defined asmskipthickmuskipand inserts a horizontal space of lengththickmuskip, which by default is5mubut can be stretched to10muif necessary.mkernis similar tomskip, but it doesn't allow for stretching. Somkern-thickmuskipremoves a horizontal space of5muin this case so that we end up with a horizontal space of0muthat can be stretched to up to5mu. See this answer for more information on spacing commands.
A possible disadvantage of
smashstackrelcompared tostackrelis that it always typesets things indisplaystyle.
I've included a version ofsmashstackrel[l]that doesn't do this below because I had already written it before I suddenly remembered the existence ofsmashoperator.
makeatletter %% <- make @ usable in command names
newcommand*noLstackrel[2]{mathpalettenoLstackrel@{{#1}{#2}}}
newcommand*noLstackrel@[2]{noLstackrel@@{#1}#2}
newcommand*noLstackrel@@[3]{% #1 = displaystyle etc., #2 = top, #3 = bottom
begingroup %% <- limit scope of boxes
sbox0{$m@th#1stackrel{#2}{#3}$}% %% <- put stackrel construction in box 0
sbox2{$m@th#1#3$}% %% <- put base symbol in box 2
hskip.5wd2 hskip-.5wd0 %% <- remove excess width on the left
mathrel{usebox0}% %% <- print box 0
endgroup
}
makeatother %% <- revert @
Usage:
noLstackrel{<stuff on top>}{implies}.
Excellent your work and the same of @caverac.
– Sebastiano
Dec 30 '18 at 10:16
The second note is a bit hard to read because you only define the command you refer to, in the third note. Probably because you have rewritten the answer? Otherwise excellent answer. Do you think it would be a good idea to redefineimpliesin a way that it allowsimplies^{Explanation}?
– Felix B.
Dec 30 '18 at 11:23
1
@FelixB. Oops, that is indeed what happened. What you suggest sounds like a neat idea, but it seems like it'd be a bit finicky to implement if you wantimpliesto still be treated as a relation (rather than an operator) for spacing purposes and even more so if you want the left side to be "smashed" as above. Becausemathop{Longrightarrow}does neither of these things, you would have to use something like@ifnextcharto look ahead for an explicit^.
– Circumscribe
Dec 30 '18 at 11:55
If you say it might be finicky I probably better leave my hands off of it. Still trying to wrap my head around what all the commands in the second note do. And I haven't really understood the third comment (I think I know that the problem is that it treats sums limits different in()than[]but I don't understand the solution) Wouldn't usinglimitslike in the originalstackrelsolve this problem?
– Felix B.
Dec 30 '18 at 11:58
1
I've added a brief explanation to second remark. It only really matters for inline ($…$) equations though, since I don't think spaces in display environments are really ever stretched.
– Circumscribe
Dec 30 '18 at 12:18
|
show 2 more comments
The stackrel command is defined as
#1#2 → mathrel{mathop{#2}limits^{#1}}
so you could use smashoperator from the mathtools package to get rid of the space introduced by the left half of the superscript.
I'm defining smashstackrel below, a version of stackrel that incorporates smashoperator. I think smashstackrel[l] does precisely what you want.
I also defined feliximplies{<text>} to make life simpler.
documentclass{article}
usepackage{mathtools}
newcommand*smashstackrel[3][lr]{%
mathrel{smashoperator[#1]{mathop{#3}^{#2}}}
}
newcommand*feliximplies[1]{smashstackrel[l]{textnormal{#1}}{implies}}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&smashstackrel[l]{text{Explanation}}{implies}text{Third Statement}\
&feliximplies{Explanation} text{Fourth Statement}
end{align}
end{document}

Notes:
The optional argument of
smashstackrelcan be either[l],[r]or[lr]depending on whether you want to ignore the left side or the right side or both sides of the superscript for spacing purposes.
impliesis defined asDOTSB;Longrightarrow;and;produces a space that can be stretched (but not shrunk, by default).
This space will no longer be stretchable ifstackrel(orsmashstackrel) is used, so doing so feels slightly dubious.
I think something like
;mkern-thickmuskipstackrel{<text>}{implies};mkern-thickmuskip
might be more appropriate than just
stackrel{<text>}{implies}. This reinserts precisely the amount of stretchability that was lost. (The same remark applies tosmashstackrelandnoLstackrel, which is defined below.)
In this case it doesn't matter though, since here the space won't be stretched anyway. It would matter if this command were used inline rather than in a display environment.
Brief explanation:
;is defined asmskipthickmuskipand inserts a horizontal space of lengththickmuskip, which by default is5mubut can be stretched to10muif necessary.mkernis similar tomskip, but it doesn't allow for stretching. Somkern-thickmuskipremoves a horizontal space of5muin this case so that we end up with a horizontal space of0muthat can be stretched to up to5mu. See this answer for more information on spacing commands.
A possible disadvantage of
smashstackrelcompared tostackrelis that it always typesets things indisplaystyle.
I've included a version ofsmashstackrel[l]that doesn't do this below because I had already written it before I suddenly remembered the existence ofsmashoperator.
makeatletter %% <- make @ usable in command names
newcommand*noLstackrel[2]{mathpalettenoLstackrel@{{#1}{#2}}}
newcommand*noLstackrel@[2]{noLstackrel@@{#1}#2}
newcommand*noLstackrel@@[3]{% #1 = displaystyle etc., #2 = top, #3 = bottom
begingroup %% <- limit scope of boxes
sbox0{$m@th#1stackrel{#2}{#3}$}% %% <- put stackrel construction in box 0
sbox2{$m@th#1#3$}% %% <- put base symbol in box 2
hskip.5wd2 hskip-.5wd0 %% <- remove excess width on the left
mathrel{usebox0}% %% <- print box 0
endgroup
}
makeatother %% <- revert @
Usage:
noLstackrel{<stuff on top>}{implies}.
The stackrel command is defined as
#1#2 → mathrel{mathop{#2}limits^{#1}}
so you could use smashoperator from the mathtools package to get rid of the space introduced by the left half of the superscript.
I'm defining smashstackrel below, a version of stackrel that incorporates smashoperator. I think smashstackrel[l] does precisely what you want.
I also defined feliximplies{<text>} to make life simpler.
documentclass{article}
usepackage{mathtools}
newcommand*smashstackrel[3][lr]{%
mathrel{smashoperator[#1]{mathop{#3}^{#2}}}
}
newcommand*feliximplies[1]{smashstackrel[l]{textnormal{#1}}{implies}}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&smashstackrel[l]{text{Explanation}}{implies}text{Third Statement}\
&feliximplies{Explanation} text{Fourth Statement}
end{align}
end{document}

Notes:
The optional argument of
smashstackrelcan be either[l],[r]or[lr]depending on whether you want to ignore the left side or the right side or both sides of the superscript for spacing purposes.
impliesis defined asDOTSB;Longrightarrow;and;produces a space that can be stretched (but not shrunk, by default).
This space will no longer be stretchable ifstackrel(orsmashstackrel) is used, so doing so feels slightly dubious.
I think something like
;mkern-thickmuskipstackrel{<text>}{implies};mkern-thickmuskip
might be more appropriate than just
stackrel{<text>}{implies}. This reinserts precisely the amount of stretchability that was lost. (The same remark applies tosmashstackrelandnoLstackrel, which is defined below.)
In this case it doesn't matter though, since here the space won't be stretched anyway. It would matter if this command were used inline rather than in a display environment.
Brief explanation:
;is defined asmskipthickmuskipand inserts a horizontal space of lengththickmuskip, which by default is5mubut can be stretched to10muif necessary.mkernis similar tomskip, but it doesn't allow for stretching. Somkern-thickmuskipremoves a horizontal space of5muin this case so that we end up with a horizontal space of0muthat can be stretched to up to5mu. See this answer for more information on spacing commands.
A possible disadvantage of
smashstackrelcompared tostackrelis that it always typesets things indisplaystyle.
I've included a version ofsmashstackrel[l]that doesn't do this below because I had already written it before I suddenly remembered the existence ofsmashoperator.
makeatletter %% <- make @ usable in command names
newcommand*noLstackrel[2]{mathpalettenoLstackrel@{{#1}{#2}}}
newcommand*noLstackrel@[2]{noLstackrel@@{#1}#2}
newcommand*noLstackrel@@[3]{% #1 = displaystyle etc., #2 = top, #3 = bottom
begingroup %% <- limit scope of boxes
sbox0{$m@th#1stackrel{#2}{#3}$}% %% <- put stackrel construction in box 0
sbox2{$m@th#1#3$}% %% <- put base symbol in box 2
hskip.5wd2 hskip-.5wd0 %% <- remove excess width on the left
mathrel{usebox0}% %% <- print box 0
endgroup
}
makeatother %% <- revert @
Usage:
noLstackrel{<stuff on top>}{implies}.
edited Dec 30 '18 at 12:34
answered Dec 30 '18 at 1:23
Circumscribe
4,8011533
4,8011533
Excellent your work and the same of @caverac.
– Sebastiano
Dec 30 '18 at 10:16
The second note is a bit hard to read because you only define the command you refer to, in the third note. Probably because you have rewritten the answer? Otherwise excellent answer. Do you think it would be a good idea to redefineimpliesin a way that it allowsimplies^{Explanation}?
– Felix B.
Dec 30 '18 at 11:23
1
@FelixB. Oops, that is indeed what happened. What you suggest sounds like a neat idea, but it seems like it'd be a bit finicky to implement if you wantimpliesto still be treated as a relation (rather than an operator) for spacing purposes and even more so if you want the left side to be "smashed" as above. Becausemathop{Longrightarrow}does neither of these things, you would have to use something like@ifnextcharto look ahead for an explicit^.
– Circumscribe
Dec 30 '18 at 11:55
If you say it might be finicky I probably better leave my hands off of it. Still trying to wrap my head around what all the commands in the second note do. And I haven't really understood the third comment (I think I know that the problem is that it treats sums limits different in()than[]but I don't understand the solution) Wouldn't usinglimitslike in the originalstackrelsolve this problem?
– Felix B.
Dec 30 '18 at 11:58
1
I've added a brief explanation to second remark. It only really matters for inline ($…$) equations though, since I don't think spaces in display environments are really ever stretched.
– Circumscribe
Dec 30 '18 at 12:18
|
show 2 more comments
Excellent your work and the same of @caverac.
– Sebastiano
Dec 30 '18 at 10:16
The second note is a bit hard to read because you only define the command you refer to, in the third note. Probably because you have rewritten the answer? Otherwise excellent answer. Do you think it would be a good idea to redefineimpliesin a way that it allowsimplies^{Explanation}?
– Felix B.
Dec 30 '18 at 11:23
1
@FelixB. Oops, that is indeed what happened. What you suggest sounds like a neat idea, but it seems like it'd be a bit finicky to implement if you wantimpliesto still be treated as a relation (rather than an operator) for spacing purposes and even more so if you want the left side to be "smashed" as above. Becausemathop{Longrightarrow}does neither of these things, you would have to use something like@ifnextcharto look ahead for an explicit^.
– Circumscribe
Dec 30 '18 at 11:55
If you say it might be finicky I probably better leave my hands off of it. Still trying to wrap my head around what all the commands in the second note do. And I haven't really understood the third comment (I think I know that the problem is that it treats sums limits different in()than[]but I don't understand the solution) Wouldn't usinglimitslike in the originalstackrelsolve this problem?
– Felix B.
Dec 30 '18 at 11:58
1
I've added a brief explanation to second remark. It only really matters for inline ($…$) equations though, since I don't think spaces in display environments are really ever stretched.
– Circumscribe
Dec 30 '18 at 12:18
Excellent your work and the same of @caverac.
– Sebastiano
Dec 30 '18 at 10:16
Excellent your work and the same of @caverac.
– Sebastiano
Dec 30 '18 at 10:16
The second note is a bit hard to read because you only define the command you refer to, in the third note. Probably because you have rewritten the answer? Otherwise excellent answer. Do you think it would be a good idea to redefine
implies in a way that it allows implies^{Explanation}?– Felix B.
Dec 30 '18 at 11:23
The second note is a bit hard to read because you only define the command you refer to, in the third note. Probably because you have rewritten the answer? Otherwise excellent answer. Do you think it would be a good idea to redefine
implies in a way that it allows implies^{Explanation}?– Felix B.
Dec 30 '18 at 11:23
1
1
@FelixB. Oops, that is indeed what happened. What you suggest sounds like a neat idea, but it seems like it'd be a bit finicky to implement if you want
implies to still be treated as a relation (rather than an operator) for spacing purposes and even more so if you want the left side to be "smashed" as above. Because mathop{Longrightarrow} does neither of these things, you would have to use something like @ifnextchar to look ahead for an explicit ^ .– Circumscribe
Dec 30 '18 at 11:55
@FelixB. Oops, that is indeed what happened. What you suggest sounds like a neat idea, but it seems like it'd be a bit finicky to implement if you want
implies to still be treated as a relation (rather than an operator) for spacing purposes and even more so if you want the left side to be "smashed" as above. Because mathop{Longrightarrow} does neither of these things, you would have to use something like @ifnextchar to look ahead for an explicit ^ .– Circumscribe
Dec 30 '18 at 11:55
If you say it might be finicky I probably better leave my hands off of it. Still trying to wrap my head around what all the commands in the second note do. And I haven't really understood the third comment (I think I know that the problem is that it treats sums limits different in
() than [] but I don't understand the solution) Wouldn't using limits like in the original stackrel solve this problem?– Felix B.
Dec 30 '18 at 11:58
If you say it might be finicky I probably better leave my hands off of it. Still trying to wrap my head around what all the commands in the second note do. And I haven't really understood the third comment (I think I know that the problem is that it treats sums limits different in
() than [] but I don't understand the solution) Wouldn't using limits like in the original stackrel solve this problem?– Felix B.
Dec 30 '18 at 11:58
1
1
I've added a brief explanation to second remark. It only really matters for inline (
$…$) equations though, since I don't think spaces in display environments are really ever stretched.– Circumscribe
Dec 30 '18 at 12:18
I've added a brief explanation to second remark. It only really matters for inline (
$…$) equations though, since I don't think spaces in display environments are really ever stretched.– Circumscribe
Dec 30 '18 at 12:18
|
show 2 more comments
You could try eqnarray
begin{eqnarray}
&& text{First Statement}\
&implies& text{Second Statement}\
&stackrel{text{Explanation}}{implies}&text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies}& text{Fourth Statement}
end{eqnarray}

2
tex.stackexchange.com/questions/196/eqnarray-vs-align judging from the most popular answer that might not be the best idea?
– Felix B.
Dec 29 '18 at 13:46
@FelixB. You are absolutely right! I will leave it here until someone else gives you a better solution
– caverac
Dec 29 '18 at 14:03
add a comment |
You could try eqnarray
begin{eqnarray}
&& text{First Statement}\
&implies& text{Second Statement}\
&stackrel{text{Explanation}}{implies}&text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies}& text{Fourth Statement}
end{eqnarray}

2
tex.stackexchange.com/questions/196/eqnarray-vs-align judging from the most popular answer that might not be the best idea?
– Felix B.
Dec 29 '18 at 13:46
@FelixB. You are absolutely right! I will leave it here until someone else gives you a better solution
– caverac
Dec 29 '18 at 14:03
add a comment |
You could try eqnarray
begin{eqnarray}
&& text{First Statement}\
&implies& text{Second Statement}\
&stackrel{text{Explanation}}{implies}&text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies}& text{Fourth Statement}
end{eqnarray}

You could try eqnarray
begin{eqnarray}
&& text{First Statement}\
&implies& text{Second Statement}\
&stackrel{text{Explanation}}{implies}&text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies}& text{Fourth Statement}
end{eqnarray}

answered Dec 29 '18 at 13:41
caverac
5,9281624
5,9281624
2
tex.stackexchange.com/questions/196/eqnarray-vs-align judging from the most popular answer that might not be the best idea?
– Felix B.
Dec 29 '18 at 13:46
@FelixB. You are absolutely right! I will leave it here until someone else gives you a better solution
– caverac
Dec 29 '18 at 14:03
add a comment |
2
tex.stackexchange.com/questions/196/eqnarray-vs-align judging from the most popular answer that might not be the best idea?
– Felix B.
Dec 29 '18 at 13:46
@FelixB. You are absolutely right! I will leave it here until someone else gives you a better solution
– caverac
Dec 29 '18 at 14:03
2
2
tex.stackexchange.com/questions/196/eqnarray-vs-align judging from the most popular answer that might not be the best idea?
– Felix B.
Dec 29 '18 at 13:46
tex.stackexchange.com/questions/196/eqnarray-vs-align judging from the most popular answer that might not be the best idea?
– Felix B.
Dec 29 '18 at 13:46
@FelixB. You are absolutely right! I will leave it here until someone else gives you a better solution
– caverac
Dec 29 '18 at 14:03
@FelixB. You are absolutely right! I will leave it here until someone else gives you a better solution
– caverac
Dec 29 '18 at 14:03
add a comment |
Reading the documentation on mathtools after learning about smashoperators from Circumscribes answer, I found another possible solution: xRightarrow
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{Statement}\
&implies text{implies arrow}\
&xRightarrow{text{Explanation}}text{xRightarrow}\
&xRightarrow{(*)} text{xRightarrow}\
&;xRightarrow{(*)}; text{xRightarrow with ;}\
&implies text{implies arrow}\
&;xRightarrow{}; text{xRightarrow with ;}\
&;Rightarrow; text{Rightarrow with ;}
end{align}
end{document}
Resulting in:

The advantage of this solution is, that it utilizes a command from a known package, which probably has less errors than a home cooked solution. And it allows for underscript too.
The disadvantage is probably clear from the picture. implies inserts a space before the arrow, which xRightarrow does not do.
(EDIT: this can be fixed with ; at the sides as Circumscribes points out but it is still noticeable that xRightarrow is based on Rightarrow, as you can see from the default length when there is no input)
So instead of implies you would probably have to use Rightarrow instead. Secondly I am not sure if I visually prefer different length arrows over explanations which overflow the width of the usual implies arrow.
Seems like a good solution. To make the spacing match that ofimpliesyou should use;xRightarrow{…};, sinceimpliesis effectively the same thing as;Longrightarrow;.
– Circumscribe
Dec 30 '18 at 14:15
add a comment |
Reading the documentation on mathtools after learning about smashoperators from Circumscribes answer, I found another possible solution: xRightarrow
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{Statement}\
&implies text{implies arrow}\
&xRightarrow{text{Explanation}}text{xRightarrow}\
&xRightarrow{(*)} text{xRightarrow}\
&;xRightarrow{(*)}; text{xRightarrow with ;}\
&implies text{implies arrow}\
&;xRightarrow{}; text{xRightarrow with ;}\
&;Rightarrow; text{Rightarrow with ;}
end{align}
end{document}
Resulting in:

The advantage of this solution is, that it utilizes a command from a known package, which probably has less errors than a home cooked solution. And it allows for underscript too.
The disadvantage is probably clear from the picture. implies inserts a space before the arrow, which xRightarrow does not do.
(EDIT: this can be fixed with ; at the sides as Circumscribes points out but it is still noticeable that xRightarrow is based on Rightarrow, as you can see from the default length when there is no input)
So instead of implies you would probably have to use Rightarrow instead. Secondly I am not sure if I visually prefer different length arrows over explanations which overflow the width of the usual implies arrow.
Seems like a good solution. To make the spacing match that ofimpliesyou should use;xRightarrow{…};, sinceimpliesis effectively the same thing as;Longrightarrow;.
– Circumscribe
Dec 30 '18 at 14:15
add a comment |
Reading the documentation on mathtools after learning about smashoperators from Circumscribes answer, I found another possible solution: xRightarrow
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{Statement}\
&implies text{implies arrow}\
&xRightarrow{text{Explanation}}text{xRightarrow}\
&xRightarrow{(*)} text{xRightarrow}\
&;xRightarrow{(*)}; text{xRightarrow with ;}\
&implies text{implies arrow}\
&;xRightarrow{}; text{xRightarrow with ;}\
&;Rightarrow; text{Rightarrow with ;}
end{align}
end{document}
Resulting in:

The advantage of this solution is, that it utilizes a command from a known package, which probably has less errors than a home cooked solution. And it allows for underscript too.
The disadvantage is probably clear from the picture. implies inserts a space before the arrow, which xRightarrow does not do.
(EDIT: this can be fixed with ; at the sides as Circumscribes points out but it is still noticeable that xRightarrow is based on Rightarrow, as you can see from the default length when there is no input)
So instead of implies you would probably have to use Rightarrow instead. Secondly I am not sure if I visually prefer different length arrows over explanations which overflow the width of the usual implies arrow.
Reading the documentation on mathtools after learning about smashoperators from Circumscribes answer, I found another possible solution: xRightarrow
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{Statement}\
&implies text{implies arrow}\
&xRightarrow{text{Explanation}}text{xRightarrow}\
&xRightarrow{(*)} text{xRightarrow}\
&;xRightarrow{(*)}; text{xRightarrow with ;}\
&implies text{implies arrow}\
&;xRightarrow{}; text{xRightarrow with ;}\
&;Rightarrow; text{Rightarrow with ;}
end{align}
end{document}
Resulting in:

The advantage of this solution is, that it utilizes a command from a known package, which probably has less errors than a home cooked solution. And it allows for underscript too.
The disadvantage is probably clear from the picture. implies inserts a space before the arrow, which xRightarrow does not do.
(EDIT: this can be fixed with ; at the sides as Circumscribes points out but it is still noticeable that xRightarrow is based on Rightarrow, as you can see from the default length when there is no input)
So instead of implies you would probably have to use Rightarrow instead. Secondly I am not sure if I visually prefer different length arrows over explanations which overflow the width of the usual implies arrow.
edited Dec 30 '18 at 14:30
answered Dec 30 '18 at 14:07
Felix B.
1458
1458
Seems like a good solution. To make the spacing match that ofimpliesyou should use;xRightarrow{…};, sinceimpliesis effectively the same thing as;Longrightarrow;.
– Circumscribe
Dec 30 '18 at 14:15
add a comment |
Seems like a good solution. To make the spacing match that ofimpliesyou should use;xRightarrow{…};, sinceimpliesis effectively the same thing as;Longrightarrow;.
– Circumscribe
Dec 30 '18 at 14:15
Seems like a good solution. To make the spacing match that of
implies you should use ;xRightarrow{…};, since implies is effectively the same thing as ;Longrightarrow;.– Circumscribe
Dec 30 '18 at 14:15
Seems like a good solution. To make the spacing match that of
implies you should use ;xRightarrow{…};, since implies is effectively the same thing as ;Longrightarrow;.– Circumscribe
Dec 30 '18 at 14:15
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f467779%2falignment-of-implication-arrows-with-text-on-top%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
Can you add a full compilable code, please? For example I have not understood your question.
– Sebastiano
Dec 29 '18 at 13:22
@Sebastiano like this?
– Felix B.
Dec 29 '18 at 13:27
Ok :-)Thank you very much.
– Sebastiano
Dec 29 '18 at 13:28
1
i see no reason that using a
phantomwon't work. for the first statement, use thephantomwith the whole content of thestackrelwith the longest text. for the second, use thephantomfor just the top element of thestackrel. some adjustment will be necessary if two "printed" explanations" have different widths. i can't test this now since i don't have tex installed on my laptop.– barbara beeton
Dec 30 '18 at 0:25