Geometry affects line breakingLine breaking and floatingRounded box around placeholder text that supports line breakingHbox overfull: automatic linebreaks on spacesLine breaking in equationDiscourage line breaking after short wordsLine breaking in newcommand
Double feature: In concert
Why didn't Aboriginal Australians invent agriculture?
How to get previous command without arrow key
Masyu keep making those 3D puzzles?
Endless disc brake issues
Is there anyone who understand this symbol of Jetson nano based board schematics?
Replace long GROUP BY list with a subquery
Bass - describe attacking one note in one or more bars
Another gcd problem
Do I need a visa for Japan as a New Zealand Citizen?
Do you still need a Test Plan when adopting Continuous Delivery?
How do I get softer pictures in sunlight, like in this commercial?
Showing a homeless person that you care about their well-being
SpaceX Starship landing on Moon or Mars: why doesn't it fall over?
How to electrically ground a gas furnace connected with an armoured cable
Deadlock Graph - Surviving Statement inputbuf does not show the object that was locked
I love fishing, dancing, playing, crafting, and fighting
What does "Cheer up" mean?
How to determine if the current Ubuntu installation is minimal?
Why doesn't the nucleus have "nucleus-probability cloud"?
Find the closest enemy
Python: write 2**n - 1 as a recursive function
RAM stress test
Why not 1.d4 Nf6 2.d5?
Geometry affects line breaking
Line breaking and floatingRounded box around placeholder text that supports line breakingHbox overfull: automatic linebreaks on spacesLine breaking in equationDiscourage line breaking after short wordsLine breaking in newcommand
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty
margin-bottom:0;
This one has me stumped. The idea is to pack boxes (in this case, rule) together tightly while allowing them to break at the end of a line. It works without geometry, but not with.
Another package (which I haven't isolated yet) causes gaps between the boxes.
documentclassarticle
usepackagegeometry% works when commented out
newcommandblockrule0.5textwidth1ptallowbreak
parindent=0pt
begindocument
block
block
block
block
enddocument
line-breaking boxes geometry
edited May 28 at 21:53
David Carlisle
526k44 gold badges1191 silver badges1967 bronze badges
asked May 28 at 21:39
John KormyloJohn Kormylo
50.3k3 gold badges29 silver badges76 bronze badges
add a comment
|
This one has me stumped. The idea is to pack boxes (in this case, rule) together tightly while allowing them to break at the end of a line. It works without geometry, but not with.
Another package (which I haven't isolated yet) causes gaps between the boxes.
documentclassarticle
usepackagegeometry% works when commented out
newcommandblockrule0.5textwidth1ptallowbreak
parindent=0pt
begindocument
block
block
block
block
enddocument
line-breaking boxes geometry
edited May 28 at 21:53
David Carlisle
526k44 gold badges1191 silver badges1967 bronze badges
asked May 28 at 21:39
John KormyloJohn Kormylo
50.3k3 gold badges29 silver badges76 bronze badges
add a comment
|
This one has me stumped. The idea is to pack boxes (in this case, rule) together tightly while allowing them to break at the end of a line. It works without geometry, but not with.
Another package (which I haven't isolated yet) causes gaps between the boxes.
documentclassarticle
usepackagegeometry% works when commented out
newcommandblockrule0.5textwidth1ptallowbreak
parindent=0pt
begindocument
block
block
block
block
enddocument
line-breaking boxes geometry
edited May 28 at 21:53
David Carlisle
526k44 gold badges1191 silver badges1967 bronze badges
asked May 28 at 21:39
John KormyloJohn Kormylo
50.3k3 gold badges29 silver badges76 bronze badges
This one has me stumped. The idea is to pack boxes (in this case, rule) together tightly while allowing them to break at the end of a line. It works without geometry, but not with.
Another package (which I haven't isolated yet) causes gaps between the boxes.
documentclassarticle
usepackagegeometry% works when commented out
newcommandblockrule0.5textwidth1ptallowbreak
parindent=0pt
begindocument
block
block
block
block
enddocument
line-breaking boxes geometry
line-breaking boxes geometry
edited May 28 at 21:53
David Carlisle
526k44 gold badges1191 silver badges1967 bronze badges
asked May 28 at 21:39
John KormyloJohn Kormylo
50.3k3 gold badges29 silver badges76 bronze badges
edited May 28 at 21:53
David Carlisle
526k44 gold badges1191 silver badges1967 bronze badges
asked May 28 at 21:39
John KormyloJohn Kormylo
50.3k3 gold badges29 silver badges76 bronze badges
edited May 28 at 21:53
David Carlisle
526k44 gold badges1191 silver badges1967 bronze badges
edited May 28 at 21:53
David Carlisle
526k44 gold badges1191 silver badges1967 bronze badges
edited May 28 at 21:53
David Carlisle
526k44 gold badges1191 silver badges1967 bronze badges
526k44 gold badges1191 silver badges1967 bronze badges
asked May 28 at 21:39
John KormyloJohn Kormylo
50.3k3 gold badges29 silver badges76 bronze badges
asked May 28 at 21:39
John KormyloJohn Kormylo
50.3k3 gold badges29 silver badges76 bronze badges
asked May 28 at 21:39
John KormyloJohn Kormylo
50.3k3 gold badges29 silver badges76 bronze badges
50.3k3 gold badges29 silver badges76 bronze badges
add a comment
|
add a comment
|
2 Answers
2
active
oldest
votes
geometry changes the page size unless you use options to prevent that,
documentclassarticle
showthetextwidth
usepackagegeometry% works when commented out
showthetextwidth
newcommandblockrule0.5textwidth1ptallowbreak
parindent=0pt
begindocument
block
block
block
block
enddocument
You see the same without geometry but with the same page width
documentclassarticle
textwidth=430.00462pt
newcommandblockrule0.5textwidth1ptallowbreak
parindent=0pt
begindocument
block
block
block
block
enddocument
In either case, due to rounding errors, you can't fit two blocks exactly filling a line.....
edited May 29 at 4:00
Community♦
1
answered May 28 at 21:42
David CarlisleDavid Carlisle
526k44 gold badges1191 silver badges1967 bronze badges
Ah, yes, rounding errors... So, a tiny-tiny bit of stretchable and shrinkable glue should be enough in all cases, right?
– frougon
May 28 at 21:48
So why does it try to cram 3 in where even two won't fit? Aha, I need some glue!
– John Kormylo
May 28 at 21:49
I guess: when the rounding errors say that two aren't enough, there we are: let's take a third one...
– frougon
May 28 at 21:50
1
@frougon yes in this case two blocks are 1sp short of a line but there is no flexibility so tex tries to stuff another block into that 1sp of space.....
– David Carlisle
May 28 at 21:51
BTW,hspace0pt plus 1pt minus 1ptfixes the problem.
– John Kormylo
May 28 at 22:03
|
show 1 more comment
According to TeX, 0.5textwidth+0.5textwidth may not be equal to textwidth.
When geometry sets the text width to 430.00462pt, this is precisely what happens. The sum of the widths of two rules falls 1sp short of the textwidth and TeX tries to stick another rule in the first line, having no stretchability available.
However, you can do more accurate computations:
documentclassarticle
usepackagegeometry% works when commented out
usepackagexfp
newcommandblockrulefpeval0.5textwidthpt1ptallowbreak
parindent=0pt
begindocument
block
block
block
blockunpenalty % to avoid the spurious underfull box message
bigskip
begintabular[t]llll
Method & half & half + half & text width\
hline
TeX & thedimexpr 0.5textwidthrelax & thedimexpr 0.5textwidth + 0.5textwidthrelax &
thetextwidth \
l3fp & fpeval0.5textwidthpt & fpeval0.5textwidth+0.5textwidthpt
endtabular
enddocument
The length 0.5textwidth, according to TeX is 14090391sp, whereas the text width is 28180783.
You can solve the issue by defining the rule differenly:
documentclassarticle
usepackagegeometry% works when commented out
newcommandblockrule0.5textwidth1ptallowbreakhspace0pt plus 1sp
parindent=0pt
begindocument
block
block
block
block
enddocument
Another famous case: if you try
setbox0=hbox to 2inhskip 1in hskip 1in
you'll get Underfull hbox (badness 10000) because two one inch skips fall 1sp short of two inches.
answered May 28 at 22:18
egregegreg
775k92 gold badges2020 silver badges3381 bronze badges
Thanks for the insight! In such operations, are the rounding errors (by TeX) always towards zero, always towards$-infty$, or is it variable? (in the last case, unless I'm mistaken, yourhspace0pt plus 1spsolution would rely on a large enough value ofhfuzz—like David Carlisle'sraggedright, BTW)
– frougon
May 28 at 22:41
1
@frougon Always truncation, sohfuzzis not really relevant, because it is about slight overfull, rather than underfull.
– egreg
May 28 at 23: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/4.0/"u003ecc by-sa 4.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%2f493111%2fgeometry-affects-line-breaking%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
geometry changes the page size unless you use options to prevent that,
documentclassarticle
showthetextwidth
usepackagegeometry% works when commented out
showthetextwidth
newcommandblockrule0.5textwidth1ptallowbreak
parindent=0pt
begindocument
block
block
block
block
enddocument
You see the same without geometry but with the same page width
documentclassarticle
textwidth=430.00462pt
newcommandblockrule0.5textwidth1ptallowbreak
parindent=0pt
begindocument
block
block
block
block
enddocument
In either case, due to rounding errors, you can't fit two blocks exactly filling a line.....
edited May 29 at 4:00
Community♦
1
answered May 28 at 21:42
David CarlisleDavid Carlisle
526k44 gold badges1191 silver badges1967 bronze badges
Ah, yes, rounding errors... So, a tiny-tiny bit of stretchable and shrinkable glue should be enough in all cases, right?
– frougon
May 28 at 21:48
So why does it try to cram 3 in where even two won't fit? Aha, I need some glue!
– John Kormylo
May 28 at 21:49
I guess: when the rounding errors say that two aren't enough, there we are: let's take a third one...
– frougon
May 28 at 21:50
1
@frougon yes in this case two blocks are 1sp short of a line but there is no flexibility so tex tries to stuff another block into that 1sp of space.....
– David Carlisle
May 28 at 21:51
BTW,hspace0pt plus 1pt minus 1ptfixes the problem.
– John Kormylo
May 28 at 22:03
|
show 1 more comment
geometry changes the page size unless you use options to prevent that,
documentclassarticle
showthetextwidth
usepackagegeometry% works when commented out
showthetextwidth
newcommandblockrule0.5textwidth1ptallowbreak
parindent=0pt
begindocument
block
block
block
block
enddocument
You see the same without geometry but with the same page width
documentclassarticle
textwidth=430.00462pt
newcommandblockrule0.5textwidth1ptallowbreak
parindent=0pt
begindocument
block
block
block
block
enddocument
In either case, due to rounding errors, you can't fit two blocks exactly filling a line.....
edited May 29 at 4:00
Community♦
1
answered May 28 at 21:42
David CarlisleDavid Carlisle
526k44 gold badges1191 silver badges1967 bronze badges
Ah, yes, rounding errors... So, a tiny-tiny bit of stretchable and shrinkable glue should be enough in all cases, right?
– frougon
May 28 at 21:48
So why does it try to cram 3 in where even two won't fit? Aha, I need some glue!
– John Kormylo
May 28 at 21:49
I guess: when the rounding errors say that two aren't enough, there we are: let's take a third one...
– frougon
May 28 at 21:50
1
@frougon yes in this case two blocks are 1sp short of a line but there is no flexibility so tex tries to stuff another block into that 1sp of space.....
– David Carlisle
May 28 at 21:51
BTW,hspace0pt plus 1pt minus 1ptfixes the problem.
– John Kormylo
May 28 at 22:03
|
show 1 more comment
geometry changes the page size unless you use options to prevent that,
documentclassarticle
showthetextwidth
usepackagegeometry% works when commented out
showthetextwidth
newcommandblockrule0.5textwidth1ptallowbreak
parindent=0pt
begindocument
block
block
block
block
enddocument
You see the same without geometry but with the same page width
documentclassarticle
textwidth=430.00462pt
newcommandblockrule0.5textwidth1ptallowbreak
parindent=0pt
begindocument
block
block
block
block
enddocument
In either case, due to rounding errors, you can't fit two blocks exactly filling a line.....
edited May 29 at 4:00
Community♦
1
answered May 28 at 21:42
David CarlisleDavid Carlisle
526k44 gold badges1191 silver badges1967 bronze badges
geometry changes the page size unless you use options to prevent that,
documentclassarticle
showthetextwidth
usepackagegeometry% works when commented out
showthetextwidth
newcommandblockrule0.5textwidth1ptallowbreak
parindent=0pt
begindocument
block
block
block
block
enddocument
You see the same without geometry but with the same page width
documentclassarticle
textwidth=430.00462pt
newcommandblockrule0.5textwidth1ptallowbreak
parindent=0pt
begindocument
block
block
block
block
enddocument
In either case, due to rounding errors, you can't fit two blocks exactly filling a line.....
edited May 29 at 4:00
Community♦
1
answered May 28 at 21:42
David CarlisleDavid Carlisle
526k44 gold badges1191 silver badges1967 bronze badges
edited May 29 at 4:00
Community♦
1
edited May 29 at 4:00
Community♦
1
edited May 29 at 4:00
Community♦
1
1
answered May 28 at 21:42
David CarlisleDavid Carlisle
526k44 gold badges1191 silver badges1967 bronze badges
answered May 28 at 21:42
David CarlisleDavid Carlisle
526k44 gold badges1191 silver badges1967 bronze badges
answered May 28 at 21:42
David CarlisleDavid Carlisle
526k44 gold badges1191 silver badges1967 bronze badges
526k44 gold badges1191 silver badges1967 bronze badges
Ah, yes, rounding errors... So, a tiny-tiny bit of stretchable and shrinkable glue should be enough in all cases, right?
– frougon
May 28 at 21:48
So why does it try to cram 3 in where even two won't fit? Aha, I need some glue!
– John Kormylo
May 28 at 21:49
I guess: when the rounding errors say that two aren't enough, there we are: let's take a third one...
– frougon
May 28 at 21:50
1
@frougon yes in this case two blocks are 1sp short of a line but there is no flexibility so tex tries to stuff another block into that 1sp of space.....
– David Carlisle
May 28 at 21:51
BTW,hspace0pt plus 1pt minus 1ptfixes the problem.
– John Kormylo
May 28 at 22:03
|
show 1 more comment
Ah, yes, rounding errors... So, a tiny-tiny bit of stretchable and shrinkable glue should be enough in all cases, right?
– frougon
May 28 at 21:48
So why does it try to cram 3 in where even two won't fit? Aha, I need some glue!
– John Kormylo
May 28 at 21:49
I guess: when the rounding errors say that two aren't enough, there we are: let's take a third one...
– frougon
May 28 at 21:50
1
@frougon yes in this case two blocks are 1sp short of a line but there is no flexibility so tex tries to stuff another block into that 1sp of space.....
– David Carlisle
May 28 at 21:51
BTW,hspace0pt plus 1pt minus 1ptfixes the problem.
– John Kormylo
May 28 at 22:03
Ah, yes, rounding errors... So, a tiny-tiny bit of stretchable and shrinkable glue should be enough in all cases, right?
– frougon
May 28 at 21:48
Ah, yes, rounding errors... So, a tiny-tiny bit of stretchable and shrinkable glue should be enough in all cases, right?
– frougon
May 28 at 21:48
So why does it try to cram 3 in where even two won't fit? Aha, I need some glue!
– John Kormylo
May 28 at 21:49
So why does it try to cram 3 in where even two won't fit? Aha, I need some glue!
– John Kormylo
May 28 at 21:49
I guess: when the rounding errors say that two aren't enough, there we are: let's take a third one...
– frougon
May 28 at 21:50
I guess: when the rounding errors say that two aren't enough, there we are: let's take a third one...
– frougon
May 28 at 21:50
1
1
@frougon yes in this case two blocks are 1sp short of a line but there is no flexibility so tex tries to stuff another block into that 1sp of space.....
– David Carlisle
May 28 at 21:51
@frougon yes in this case two blocks are 1sp short of a line but there is no flexibility so tex tries to stuff another block into that 1sp of space.....
– David Carlisle
May 28 at 21:51
BTW,
hspace0pt plus 1pt minus 1pt fixes the problem.– John Kormylo
May 28 at 22:03
BTW,
hspace0pt plus 1pt minus 1pt fixes the problem.– John Kormylo
May 28 at 22:03
|
show 1 more comment
According to TeX, 0.5textwidth+0.5textwidth may not be equal to textwidth.
When geometry sets the text width to 430.00462pt, this is precisely what happens. The sum of the widths of two rules falls 1sp short of the textwidth and TeX tries to stick another rule in the first line, having no stretchability available.
However, you can do more accurate computations:
documentclassarticle
usepackagegeometry% works when commented out
usepackagexfp
newcommandblockrulefpeval0.5textwidthpt1ptallowbreak
parindent=0pt
begindocument
block
block
block
blockunpenalty % to avoid the spurious underfull box message
bigskip
begintabular[t]llll
Method & half & half + half & text width\
hline
TeX & thedimexpr 0.5textwidthrelax & thedimexpr 0.5textwidth + 0.5textwidthrelax &
thetextwidth \
l3fp & fpeval0.5textwidthpt & fpeval0.5textwidth+0.5textwidthpt
endtabular
enddocument
The length 0.5textwidth, according to TeX is 14090391sp, whereas the text width is 28180783.
You can solve the issue by defining the rule differenly:
documentclassarticle
usepackagegeometry% works when commented out
newcommandblockrule0.5textwidth1ptallowbreakhspace0pt plus 1sp
parindent=0pt
begindocument
block
block
block
block
enddocument
Another famous case: if you try
setbox0=hbox to 2inhskip 1in hskip 1in
you'll get Underfull hbox (badness 10000) because two one inch skips fall 1sp short of two inches.
answered May 28 at 22:18
egregegreg
775k92 gold badges2020 silver badges3381 bronze badges
Thanks for the insight! In such operations, are the rounding errors (by TeX) always towards zero, always towards$-infty$, or is it variable? (in the last case, unless I'm mistaken, yourhspace0pt plus 1spsolution would rely on a large enough value ofhfuzz—like David Carlisle'sraggedright, BTW)
– frougon
May 28 at 22:41
1
@frougon Always truncation, sohfuzzis not really relevant, because it is about slight overfull, rather than underfull.
– egreg
May 28 at 23:15
add a comment
|
According to TeX, 0.5textwidth+0.5textwidth may not be equal to textwidth.
When geometry sets the text width to 430.00462pt, this is precisely what happens. The sum of the widths of two rules falls 1sp short of the textwidth and TeX tries to stick another rule in the first line, having no stretchability available.
However, you can do more accurate computations:
documentclassarticle
usepackagegeometry% works when commented out
usepackagexfp
newcommandblockrulefpeval0.5textwidthpt1ptallowbreak
parindent=0pt
begindocument
block
block
block
blockunpenalty % to avoid the spurious underfull box message
bigskip
begintabular[t]llll
Method & half & half + half & text width\
hline
TeX & thedimexpr 0.5textwidthrelax & thedimexpr 0.5textwidth + 0.5textwidthrelax &
thetextwidth \
l3fp & fpeval0.5textwidthpt & fpeval0.5textwidth+0.5textwidthpt
endtabular
enddocument
The length 0.5textwidth, according to TeX is 14090391sp, whereas the text width is 28180783.
You can solve the issue by defining the rule differenly:
documentclassarticle
usepackagegeometry% works when commented out
newcommandblockrule0.5textwidth1ptallowbreakhspace0pt plus 1sp
parindent=0pt
begindocument
block
block
block
block
enddocument
Another famous case: if you try
setbox0=hbox to 2inhskip 1in hskip 1in
you'll get Underfull hbox (badness 10000) because two one inch skips fall 1sp short of two inches.
answered May 28 at 22:18
egregegreg
775k92 gold badges2020 silver badges3381 bronze badges
Thanks for the insight! In such operations, are the rounding errors (by TeX) always towards zero, always towards$-infty$, or is it variable? (in the last case, unless I'm mistaken, yourhspace0pt plus 1spsolution would rely on a large enough value ofhfuzz—like David Carlisle'sraggedright, BTW)
– frougon
May 28 at 22:41
1
@frougon Always truncation, sohfuzzis not really relevant, because it is about slight overfull, rather than underfull.
– egreg
May 28 at 23:15
add a comment
|
According to TeX, 0.5textwidth+0.5textwidth may not be equal to textwidth.
When geometry sets the text width to 430.00462pt, this is precisely what happens. The sum of the widths of two rules falls 1sp short of the textwidth and TeX tries to stick another rule in the first line, having no stretchability available.
However, you can do more accurate computations:
documentclassarticle
usepackagegeometry% works when commented out
usepackagexfp
newcommandblockrulefpeval0.5textwidthpt1ptallowbreak
parindent=0pt
begindocument
block
block
block
blockunpenalty % to avoid the spurious underfull box message
bigskip
begintabular[t]llll
Method & half & half + half & text width\
hline
TeX & thedimexpr 0.5textwidthrelax & thedimexpr 0.5textwidth + 0.5textwidthrelax &
thetextwidth \
l3fp & fpeval0.5textwidthpt & fpeval0.5textwidth+0.5textwidthpt
endtabular
enddocument
The length 0.5textwidth, according to TeX is 14090391sp, whereas the text width is 28180783.
You can solve the issue by defining the rule differenly:
documentclassarticle
usepackagegeometry% works when commented out
newcommandblockrule0.5textwidth1ptallowbreakhspace0pt plus 1sp
parindent=0pt
begindocument
block
block
block
block
enddocument
Another famous case: if you try
setbox0=hbox to 2inhskip 1in hskip 1in
you'll get Underfull hbox (badness 10000) because two one inch skips fall 1sp short of two inches.
answered May 28 at 22:18
egregegreg
775k92 gold badges2020 silver badges3381 bronze badges
According to TeX, 0.5textwidth+0.5textwidth may not be equal to textwidth.
When geometry sets the text width to 430.00462pt, this is precisely what happens. The sum of the widths of two rules falls 1sp short of the textwidth and TeX tries to stick another rule in the first line, having no stretchability available.
However, you can do more accurate computations:
documentclassarticle
usepackagegeometry% works when commented out
usepackagexfp
newcommandblockrulefpeval0.5textwidthpt1ptallowbreak
parindent=0pt
begindocument
block
block
block
blockunpenalty % to avoid the spurious underfull box message
bigskip
begintabular[t]llll
Method & half & half + half & text width\
hline
TeX & thedimexpr 0.5textwidthrelax & thedimexpr 0.5textwidth + 0.5textwidthrelax &
thetextwidth \
l3fp & fpeval0.5textwidthpt & fpeval0.5textwidth+0.5textwidthpt
endtabular
enddocument
The length 0.5textwidth, according to TeX is 14090391sp, whereas the text width is 28180783.
You can solve the issue by defining the rule differenly:
documentclassarticle
usepackagegeometry% works when commented out
newcommandblockrule0.5textwidth1ptallowbreakhspace0pt plus 1sp
parindent=0pt
begindocument
block
block
block
block
enddocument
Another famous case: if you try
setbox0=hbox to 2inhskip 1in hskip 1in
you'll get Underfull hbox (badness 10000) because two one inch skips fall 1sp short of two inches.
answered May 28 at 22:18
egregegreg
775k92 gold badges2020 silver badges3381 bronze badges
edited May 28 at 22:24
answered May 28 at 22:18
egregegreg
775k92 gold badges2020 silver badges3381 bronze badges
answered May 28 at 22:18
egregegreg
775k92 gold badges2020 silver badges3381 bronze badges
answered May 28 at 22:18
egregegreg
775k92 gold badges2020 silver badges3381 bronze badges
775k92 gold badges2020 silver badges3381 bronze badges
Thanks for the insight! In such operations, are the rounding errors (by TeX) always towards zero, always towards$-infty$, or is it variable? (in the last case, unless I'm mistaken, yourhspace0pt plus 1spsolution would rely on a large enough value ofhfuzz—like David Carlisle'sraggedright, BTW)
– frougon
May 28 at 22:41
1
@frougon Always truncation, sohfuzzis not really relevant, because it is about slight overfull, rather than underfull.
– egreg
May 28 at 23:15
add a comment
|
Thanks for the insight! In such operations, are the rounding errors (by TeX) always towards zero, always towards$-infty$, or is it variable? (in the last case, unless I'm mistaken, yourhspace0pt plus 1spsolution would rely on a large enough value ofhfuzz—like David Carlisle'sraggedright, BTW)
– frougon
May 28 at 22:41
1
@frougon Always truncation, sohfuzzis not really relevant, because it is about slight overfull, rather than underfull.
– egreg
May 28 at 23:15
Thanks for the insight! In such operations, are the rounding errors (by TeX) always towards zero, always towards
$-infty$, or is it variable? (in the last case, unless I'm mistaken, your hspace0pt plus 1sp solution would rely on a large enough value of hfuzz—like David Carlisle's raggedright, BTW)– frougon
May 28 at 22:41
Thanks for the insight! In such operations, are the rounding errors (by TeX) always towards zero, always towards
$-infty$, or is it variable? (in the last case, unless I'm mistaken, your hspace0pt plus 1sp solution would rely on a large enough value of hfuzz—like David Carlisle's raggedright, BTW)– frougon
May 28 at 22:41
1
1
@frougon Always truncation, so
hfuzz is not really relevant, because it is about slight overfull, rather than underfull.– egreg
May 28 at 23:15
@frougon Always truncation, so
hfuzz is not really relevant, because it is about slight overfull, rather than underfull.– egreg
May 28 at 23: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.
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%2f493111%2fgeometry-affects-line-breaking%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
