Spacing *inside* left and right
up vote
3
down vote
favorite
The simple formula
[ left(sum_{k=0}^infty a_kright) ]
produces an irksome, asymmetrical hiccup. The left paren is just a hair too close to the subscript of the summation and the right paren is 1.5 hairs too far to the right of the sum's term. It would be nice if I could literally just nudge the entire summation to the right a little bit, without moving the parentheses, each time I find myself in this situation. The ideal seems to be
left(mspace{1.5mu}sum_{k=0}^infty a_k!right) %requires amsmath
I really only have this problem with series; for example, integrals are fine with the default spacings because the slanted integral necessitates some whitespace:
left(int_a^b f(x)mathrm{d}xright) %perfectly fine
I thought someone would have surely asked about this already, but I haven't been able to find it (redirect me if this already exists).
I am also implementing a solution to a separate problem of spacing around left
and right
found here: Spacing around left and right that I would like this to be compatible with.
math-mode spacing amsmath parentheses
add a comment |
up vote
3
down vote
favorite
The simple formula
[ left(sum_{k=0}^infty a_kright) ]
produces an irksome, asymmetrical hiccup. The left paren is just a hair too close to the subscript of the summation and the right paren is 1.5 hairs too far to the right of the sum's term. It would be nice if I could literally just nudge the entire summation to the right a little bit, without moving the parentheses, each time I find myself in this situation. The ideal seems to be
left(mspace{1.5mu}sum_{k=0}^infty a_k!right) %requires amsmath
I really only have this problem with series; for example, integrals are fine with the default spacings because the slanted integral necessitates some whitespace:
left(int_a^b f(x)mathrm{d}xright) %perfectly fine
I thought someone would have surely asked about this already, but I haven't been able to find it (redirect me if this already exists).
I am also implementing a solution to a separate problem of spacing around left
and right
found here: Spacing around left and right that I would like this to be compatible with.
math-mode spacing amsmath parentheses
A first mistake is to employleft
andright
to auto-size the round parentheses. If you used the typographically appropriatebiggl
andbiggr
sizing macros, or maybe evenBigl
andBigr
, the left-hand-side spacing issue you’ve identified wouldn’t be an issue, and the right-hand-side spacing issue would be much less severe (or even a non-issue).
– Mico
Nov 12 at 21:11
1
For more information on why it's sometimes (or, rather, quite often) not a good idea to auto-size mathematical "fences" vialeft
andright
, see the posting Is it ever bad to use left and right?
– Mico
Nov 12 at 21:17
@Mico the use ofbigl
,biggl
, and the right versions looks a little odd to me. The textbooks that I have on hand have clearly used something more akin toleft
andright
or have avoided the construction altogether. But it is good information. However, even using those TexBook preferred methods in the answers in your link invoke the use of manual spacing. Just so that this doesn't delve into typographical taste though, I'm still looking for a parenthetical construction of series that doesn't use manual spacing repeatedly and avoids those spacing issues I've mentioned.
– Robert Wolfe
Nov 12 at 21:29
1
When I have a summation with wide limits above or below, I add,
beforesum
. This is not required and, in my opinion it's worse, withBigl(sum_{k}...
. I never useleft
andright
around big operators, the resulting size is always too big. I don't think thatmspace{1.5mu}
is sufficient in the above case;,
is the same asmspace{3mu}
.
– egreg
Nov 12 at 22:18
I've been nudged.newcommand{sparens}[1]{biggl(,#1biggr)}
works pretty well.
– Robert Wolfe
2 days ago
add a comment |
up vote
3
down vote
favorite
up vote
3
down vote
favorite
The simple formula
[ left(sum_{k=0}^infty a_kright) ]
produces an irksome, asymmetrical hiccup. The left paren is just a hair too close to the subscript of the summation and the right paren is 1.5 hairs too far to the right of the sum's term. It would be nice if I could literally just nudge the entire summation to the right a little bit, without moving the parentheses, each time I find myself in this situation. The ideal seems to be
left(mspace{1.5mu}sum_{k=0}^infty a_k!right) %requires amsmath
I really only have this problem with series; for example, integrals are fine with the default spacings because the slanted integral necessitates some whitespace:
left(int_a^b f(x)mathrm{d}xright) %perfectly fine
I thought someone would have surely asked about this already, but I haven't been able to find it (redirect me if this already exists).
I am also implementing a solution to a separate problem of spacing around left
and right
found here: Spacing around left and right that I would like this to be compatible with.
math-mode spacing amsmath parentheses
The simple formula
[ left(sum_{k=0}^infty a_kright) ]
produces an irksome, asymmetrical hiccup. The left paren is just a hair too close to the subscript of the summation and the right paren is 1.5 hairs too far to the right of the sum's term. It would be nice if I could literally just nudge the entire summation to the right a little bit, without moving the parentheses, each time I find myself in this situation. The ideal seems to be
left(mspace{1.5mu}sum_{k=0}^infty a_k!right) %requires amsmath
I really only have this problem with series; for example, integrals are fine with the default spacings because the slanted integral necessitates some whitespace:
left(int_a^b f(x)mathrm{d}xright) %perfectly fine
I thought someone would have surely asked about this already, but I haven't been able to find it (redirect me if this already exists).
I am also implementing a solution to a separate problem of spacing around left
and right
found here: Spacing around left and right that I would like this to be compatible with.
math-mode spacing amsmath parentheses
math-mode spacing amsmath parentheses
asked Nov 12 at 19:27
Robert Wolfe
1355
1355
A first mistake is to employleft
andright
to auto-size the round parentheses. If you used the typographically appropriatebiggl
andbiggr
sizing macros, or maybe evenBigl
andBigr
, the left-hand-side spacing issue you’ve identified wouldn’t be an issue, and the right-hand-side spacing issue would be much less severe (or even a non-issue).
– Mico
Nov 12 at 21:11
1
For more information on why it's sometimes (or, rather, quite often) not a good idea to auto-size mathematical "fences" vialeft
andright
, see the posting Is it ever bad to use left and right?
– Mico
Nov 12 at 21:17
@Mico the use ofbigl
,biggl
, and the right versions looks a little odd to me. The textbooks that I have on hand have clearly used something more akin toleft
andright
or have avoided the construction altogether. But it is good information. However, even using those TexBook preferred methods in the answers in your link invoke the use of manual spacing. Just so that this doesn't delve into typographical taste though, I'm still looking for a parenthetical construction of series that doesn't use manual spacing repeatedly and avoids those spacing issues I've mentioned.
– Robert Wolfe
Nov 12 at 21:29
1
When I have a summation with wide limits above or below, I add,
beforesum
. This is not required and, in my opinion it's worse, withBigl(sum_{k}...
. I never useleft
andright
around big operators, the resulting size is always too big. I don't think thatmspace{1.5mu}
is sufficient in the above case;,
is the same asmspace{3mu}
.
– egreg
Nov 12 at 22:18
I've been nudged.newcommand{sparens}[1]{biggl(,#1biggr)}
works pretty well.
– Robert Wolfe
2 days ago
add a comment |
A first mistake is to employleft
andright
to auto-size the round parentheses. If you used the typographically appropriatebiggl
andbiggr
sizing macros, or maybe evenBigl
andBigr
, the left-hand-side spacing issue you’ve identified wouldn’t be an issue, and the right-hand-side spacing issue would be much less severe (or even a non-issue).
– Mico
Nov 12 at 21:11
1
For more information on why it's sometimes (or, rather, quite often) not a good idea to auto-size mathematical "fences" vialeft
andright
, see the posting Is it ever bad to use left and right?
– Mico
Nov 12 at 21:17
@Mico the use ofbigl
,biggl
, and the right versions looks a little odd to me. The textbooks that I have on hand have clearly used something more akin toleft
andright
or have avoided the construction altogether. But it is good information. However, even using those TexBook preferred methods in the answers in your link invoke the use of manual spacing. Just so that this doesn't delve into typographical taste though, I'm still looking for a parenthetical construction of series that doesn't use manual spacing repeatedly and avoids those spacing issues I've mentioned.
– Robert Wolfe
Nov 12 at 21:29
1
When I have a summation with wide limits above or below, I add,
beforesum
. This is not required and, in my opinion it's worse, withBigl(sum_{k}...
. I never useleft
andright
around big operators, the resulting size is always too big. I don't think thatmspace{1.5mu}
is sufficient in the above case;,
is the same asmspace{3mu}
.
– egreg
Nov 12 at 22:18
I've been nudged.newcommand{sparens}[1]{biggl(,#1biggr)}
works pretty well.
– Robert Wolfe
2 days ago
A first mistake is to employ
left
and right
to auto-size the round parentheses. If you used the typographically appropriate biggl
and biggr
sizing macros, or maybe even Bigl
and Bigr
, the left-hand-side spacing issue you’ve identified wouldn’t be an issue, and the right-hand-side spacing issue would be much less severe (or even a non-issue).– Mico
Nov 12 at 21:11
A first mistake is to employ
left
and right
to auto-size the round parentheses. If you used the typographically appropriate biggl
and biggr
sizing macros, or maybe even Bigl
and Bigr
, the left-hand-side spacing issue you’ve identified wouldn’t be an issue, and the right-hand-side spacing issue would be much less severe (or even a non-issue).– Mico
Nov 12 at 21:11
1
1
For more information on why it's sometimes (or, rather, quite often) not a good idea to auto-size mathematical "fences" via
left
and right
, see the posting Is it ever bad to use left and right?– Mico
Nov 12 at 21:17
For more information on why it's sometimes (or, rather, quite often) not a good idea to auto-size mathematical "fences" via
left
and right
, see the posting Is it ever bad to use left and right?– Mico
Nov 12 at 21:17
@Mico the use of
bigl
, biggl
, and the right versions looks a little odd to me. The textbooks that I have on hand have clearly used something more akin to left
and right
or have avoided the construction altogether. But it is good information. However, even using those TexBook preferred methods in the answers in your link invoke the use of manual spacing. Just so that this doesn't delve into typographical taste though, I'm still looking for a parenthetical construction of series that doesn't use manual spacing repeatedly and avoids those spacing issues I've mentioned.– Robert Wolfe
Nov 12 at 21:29
@Mico the use of
bigl
, biggl
, and the right versions looks a little odd to me. The textbooks that I have on hand have clearly used something more akin to left
and right
or have avoided the construction altogether. But it is good information. However, even using those TexBook preferred methods in the answers in your link invoke the use of manual spacing. Just so that this doesn't delve into typographical taste though, I'm still looking for a parenthetical construction of series that doesn't use manual spacing repeatedly and avoids those spacing issues I've mentioned.– Robert Wolfe
Nov 12 at 21:29
1
1
When I have a summation with wide limits above or below, I add
,
before sum
. This is not required and, in my opinion it's worse, with Bigl(sum_{k}...
. I never use left
and right
around big operators, the resulting size is always too big. I don't think that mspace{1.5mu}
is sufficient in the above case; ,
is the same as mspace{3mu}
.– egreg
Nov 12 at 22:18
When I have a summation with wide limits above or below, I add
,
before sum
. This is not required and, in my opinion it's worse, with Bigl(sum_{k}...
. I never use left
and right
around big operators, the resulting size is always too big. I don't think that mspace{1.5mu}
is sufficient in the above case; ,
is the same as mspace{3mu}
.– egreg
Nov 12 at 22:18
I've been nudged.
newcommand{sparens}[1]{biggl(,#1biggr)}
works pretty well.– Robert Wolfe
2 days ago
I've been nudged.
newcommand{sparens}[1]{biggl(,#1biggr)}
works pretty well.– Robert Wolfe
2 days ago
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
Following the comments, newcommand{sparens}[1]{biggl(,#1biggr)}
works pretty well.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
Following the comments, newcommand{sparens}[1]{biggl(,#1biggr)}
works pretty well.
add a comment |
up vote
0
down vote
accepted
Following the comments, newcommand{sparens}[1]{biggl(,#1biggr)}
works pretty well.
add a comment |
up vote
0
down vote
accepted
up vote
0
down vote
accepted
Following the comments, newcommand{sparens}[1]{biggl(,#1biggr)}
works pretty well.
Following the comments, newcommand{sparens}[1]{biggl(,#1biggr)}
works pretty well.
answered 2 days ago
community wiki
Robert Wolfe
add a comment |
add a comment |
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%2f459678%2fspacing-inside-left-and-right%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
A first mistake is to employ
left
andright
to auto-size the round parentheses. If you used the typographically appropriatebiggl
andbiggr
sizing macros, or maybe evenBigl
andBigr
, the left-hand-side spacing issue you’ve identified wouldn’t be an issue, and the right-hand-side spacing issue would be much less severe (or even a non-issue).– Mico
Nov 12 at 21:11
1
For more information on why it's sometimes (or, rather, quite often) not a good idea to auto-size mathematical "fences" via
left
andright
, see the posting Is it ever bad to use left and right?– Mico
Nov 12 at 21:17
@Mico the use of
bigl
,biggl
, and the right versions looks a little odd to me. The textbooks that I have on hand have clearly used something more akin toleft
andright
or have avoided the construction altogether. But it is good information. However, even using those TexBook preferred methods in the answers in your link invoke the use of manual spacing. Just so that this doesn't delve into typographical taste though, I'm still looking for a parenthetical construction of series that doesn't use manual spacing repeatedly and avoids those spacing issues I've mentioned.– Robert Wolfe
Nov 12 at 21:29
1
When I have a summation with wide limits above or below, I add
,
beforesum
. This is not required and, in my opinion it's worse, withBigl(sum_{k}...
. I never useleft
andright
around big operators, the resulting size is always too big. I don't think thatmspace{1.5mu}
is sufficient in the above case;,
is the same asmspace{3mu}
.– egreg
Nov 12 at 22:18
I've been nudged.
newcommand{sparens}[1]{biggl(,#1biggr)}
works pretty well.– Robert Wolfe
2 days ago