Mdthbs

How did early x86 BIOS programmers manage to program full blown TUIs given very few bytes of ROM/EPROM?

The qvolume of an integer

Creating Fictional Slavic Place Names

What does it mean when you think without speaking?

Do creatures all have the same statistics upon being reanimated via the Animate Dead spell?

What was this black-and-white film set in the Arctic or Antarctic where the monster/alien gets fried in the end?

Did airlines fly their aircraft slower in response to oil prices in the 1970s?

Get LaTeX form from step by step solution

Will My Circuit Work As intended?

Do Multiclassed spellcasters add their ability modifier or proficiency bonus twice when determining spell save DC?

Beginner's snake game using PyGame

How to capture more stars?

Could I be denied entry into Ireland due to medical and police situations during a previous UK visit?

Could IPv6 make NAT / port numbers redundant?

Preserving culinary oils

Can an old DSLR be upgraded to match modern smartphone image quality

How do I subvert the tropes of a train heist?

What is the intuition behind uniform continuity?

Different PCB color ( is it different material? )

Is there an evolutionary advantage to having two heads?

How can I offer a test ride while selling a bike?

Is it possible to kill all life on Earth?

If a massive object like Jupiter flew past the Earth how close would it need to come to pull people off of the surface?

Select row of data if next row contains zero

Geometry affects line breaking

Line breaking and floatingRounded box around placeholder text that supports line breakingHbox overfull: automatic linebreaks on spacesLine breaking in equationLuaTeX: Line break problem with microtype + geometry (bindingoffset)New line, line breaking, `\`: a definitive answerProper way of line breakingDiscourage line breaking after short wordsLine breaking in newcommandno line breaking in mdframed with geometry package

3

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.

documentclass{article}

usepackage{geometry}% works when commented out



newcommand{block}{rule{0.5textwidth}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

block

end{document}

line-breaking boxes geometry

share|improve this question

edited 8 hours ago

David Carlisle

507k4211541906

asked 8 hours ago

John KormyloJohn Kormylo

47.7k32774

add a comment | 

3

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.

documentclass{article}

usepackage{geometry}% works when commented out



newcommand{block}{rule{0.5textwidth}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

block

end{document}

line-breaking boxes geometry

share|improve this question

edited 8 hours ago

David Carlisle

507k4211541906

asked 8 hours ago

John KormyloJohn Kormylo

47.7k32774

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.

documentclass{article}

usepackage{geometry}% works when commented out



newcommand{block}{rule{0.5textwidth}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

block

end{document}

line-breaking boxes geometry

share|improve this question

edited 8 hours ago

David Carlisle

507k4211541906

asked 8 hours ago

John KormyloJohn Kormylo

47.7k32774

documentclass{article}

usepackage{geometry}% works when commented out



newcommand{block}{rule{0.5textwidth}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

block

end{document}

share|improve this question

edited 8 hours ago

David Carlisle

507k4211541906

asked 8 hours ago

John KormyloJohn Kormylo

47.7k32774

share|improve this question

edited 8 hours ago

David Carlisle

507k4211541906

asked 8 hours ago

John KormyloJohn Kormylo

47.7k32774

edited 8 hours ago

David Carlisle

507k4211541906

edited 8 hours ago

David Carlisle

507k4211541906

asked 8 hours ago

John KormyloJohn Kormylo

47.7k32774

asked 8 hours ago

John KormyloJohn Kormylo

47.7k32774

2 Answers
2

active

oldest

votes

4

geometry changes the page size unless you use options to prevent that,

documentclass{article}

showthetextwidth

usepackage{geometry}% works when commented out

showthetextwidth



newcommand{block}{rule{0.5textwidth}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

block

end{document}

You see the same without geometry but with the same page width

documentclass{article}



textwidth=430.00462pt



newcommand{block}{rule{0.5textwidth}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

block

end{document}

In either case, due to rounding errors, you can't fit two blocks exactly filling a line.....

share|improve this answer

edited 2 hours ago

Community♦

1

answered 8 hours ago

David CarlisleDavid Carlisle

507k4211541906

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Ah, yes, rounding errors... So, a tiny-tiny bit of stretchable and shrinkable glue should be enough in all cases, right?
  
  – frougon
  8 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  So why does it try to cram 3 in where even two won't fit? Aha, I need some glue!
  
  – John Kormylo
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  I guess: when the rounding errors say that two aren't enough, there we are: let's take a third one...
  
  – frougon
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  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
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  BTW, hspace{0pt plus 1pt minus 1pt} fixes the problem.
  
  – John Kormylo
  8 hours ago
  

  
  
  
  

 | 
show 1 more comment

4

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:

documentclass{article}

usepackage{geometry}% works when commented out

usepackage{xfp}



newcommand{block}{rule{fpeval{0.5textwidth}pt}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

blockunpenalty % to avoid the spurious underfull box message



bigskip



begin{tabular}[t]{llll}

Method & half & half + half & text width\

hline

TeX & thedimexpr 0.5textwidthrelax & thedimexpr 0.5textwidth + 0.5textwidthrelax &

thetextwidth \

l3fp & fpeval{0.5textwidth}pt & fpeval{0.5textwidth+0.5textwidth}pt

end{tabular}



end{document}

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:

documentclass{article}

usepackage{geometry}% works when commented out



newcommand{block}{rule{0.5textwidth}{1pt}allowbreakhspace{0pt plus 1sp}}

parindent=0pt



begin{document}

block

block

block

block



end{document}

Another famous case: if you try

setbox0=hbox to 2in{hskip 1in hskip 1in}

you'll get Underfull hbox (badness 10000) because two one inch skips fall 1sp short of two inches.

share|improve this answer

edited 7 hours ago

answered 7 hours ago

egregegreg

745k8919493288

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  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 hspace{0pt plus 1sp} solution would rely on a large enough value of hfuzz—like David Carlisle's raggedright, BTW)
  
  – frougon
  7 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @frougon Always truncation, so hfuzz is not really relevant, because it is about slight overfull, rather than underfull.
  
  – egreg
  6 hours ago
  
  
  

  
  
  
  

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
});


}
});

draft saved

draft discarded

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

Name

Email

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

Name

Email

Required, but never shown

4

geometry changes the page size unless you use options to prevent that,

documentclass{article}

showthetextwidth

usepackage{geometry}% works when commented out

showthetextwidth



newcommand{block}{rule{0.5textwidth}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

block

end{document}

You see the same without geometry but with the same page width

documentclass{article}



textwidth=430.00462pt



newcommand{block}{rule{0.5textwidth}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

block

end{document}

In either case, due to rounding errors, you can't fit two blocks exactly filling a line.....

share|improve this answer

edited 2 hours ago

Community♦

1

answered 8 hours ago

David CarlisleDavid Carlisle

507k4211541906

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Ah, yes, rounding errors... So, a tiny-tiny bit of stretchable and shrinkable glue should be enough in all cases, right?
  
  – frougon
  8 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  So why does it try to cram 3 in where even two won't fit? Aha, I need some glue!
  
  – John Kormylo
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  I guess: when the rounding errors say that two aren't enough, there we are: let's take a third one...
  
  – frougon
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  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
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  BTW, hspace{0pt plus 1pt minus 1pt} fixes the problem.
  
  – John Kormylo
  8 hours ago
  

  
  
  
  

 | 
show 1 more comment

4

geometry changes the page size unless you use options to prevent that,

documentclass{article}

showthetextwidth

usepackage{geometry}% works when commented out

showthetextwidth



newcommand{block}{rule{0.5textwidth}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

block

end{document}

You see the same without geometry but with the same page width

documentclass{article}



textwidth=430.00462pt



newcommand{block}{rule{0.5textwidth}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

block

end{document}

In either case, due to rounding errors, you can't fit two blocks exactly filling a line.....

share|improve this answer

edited 2 hours ago

Community♦

1

answered 8 hours ago

David CarlisleDavid Carlisle

507k4211541906

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Ah, yes, rounding errors... So, a tiny-tiny bit of stretchable and shrinkable glue should be enough in all cases, right?
  
  – frougon
  8 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  So why does it try to cram 3 in where even two won't fit? Aha, I need some glue!
  
  – John Kormylo
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  I guess: when the rounding errors say that two aren't enough, there we are: let's take a third one...
  
  – frougon
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  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
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  BTW, hspace{0pt plus 1pt minus 1pt} fixes the problem.
  
  – John Kormylo
  8 hours ago
  

  
  
  
  

 | 
show 1 more comment

geometry changes the page size unless you use options to prevent that,

documentclass{article}

showthetextwidth

usepackage{geometry}% works when commented out

showthetextwidth



newcommand{block}{rule{0.5textwidth}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

block

end{document}

You see the same without geometry but with the same page width

documentclass{article}



textwidth=430.00462pt



newcommand{block}{rule{0.5textwidth}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

block

end{document}

In either case, due to rounding errors, you can't fit two blocks exactly filling a line.....

share|improve this answer

edited 2 hours ago

Community♦

1

answered 8 hours ago

David CarlisleDavid Carlisle

507k4211541906

documentclass{article}

showthetextwidth

usepackage{geometry}% works when commented out

showthetextwidth



newcommand{block}{rule{0.5textwidth}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

block

end{document}

documentclass{article}



textwidth=430.00462pt



newcommand{block}{rule{0.5textwidth}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

block

end{document}

share|improve this answer

edited 2 hours ago

Community♦

1

answered 8 hours ago

David CarlisleDavid Carlisle

507k4211541906

edited 2 hours ago

Community♦

1

edited 2 hours ago

Community♦

1

answered 8 hours ago

David CarlisleDavid Carlisle

507k4211541906

answered 8 hours ago

David CarlisleDavid Carlisle

507k4211541906

4

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:

documentclass{article}

usepackage{geometry}% works when commented out

usepackage{xfp}



newcommand{block}{rule{fpeval{0.5textwidth}pt}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

blockunpenalty % to avoid the spurious underfull box message



bigskip



begin{tabular}[t]{llll}

Method & half & half + half & text width\

hline

TeX & thedimexpr 0.5textwidthrelax & thedimexpr 0.5textwidth + 0.5textwidthrelax &

thetextwidth \

l3fp & fpeval{0.5textwidth}pt & fpeval{0.5textwidth+0.5textwidth}pt

end{tabular}



end{document}

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:

documentclass{article}

usepackage{geometry}% works when commented out



newcommand{block}{rule{0.5textwidth}{1pt}allowbreakhspace{0pt plus 1sp}}

parindent=0pt



begin{document}

block

block

block

block



end{document}

Another famous case: if you try

setbox0=hbox to 2in{hskip 1in hskip 1in}

you'll get Underfull hbox (badness 10000) because two one inch skips fall 1sp short of two inches.

share|improve this answer

edited 7 hours ago

answered 7 hours ago

egregegreg

745k8919493288

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  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 hspace{0pt plus 1sp} solution would rely on a large enough value of hfuzz—like David Carlisle's raggedright, BTW)
  
  – frougon
  7 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @frougon Always truncation, so hfuzz is not really relevant, because it is about slight overfull, rather than underfull.
  
  – egreg
  6 hours ago
  
  
  

  
  
  
  

add a comment | 

4

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:

documentclass{article}

usepackage{geometry}% works when commented out

usepackage{xfp}



newcommand{block}{rule{fpeval{0.5textwidth}pt}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

blockunpenalty % to avoid the spurious underfull box message



bigskip



begin{tabular}[t]{llll}

Method & half & half + half & text width\

hline

TeX & thedimexpr 0.5textwidthrelax & thedimexpr 0.5textwidth + 0.5textwidthrelax &

thetextwidth \

l3fp & fpeval{0.5textwidth}pt & fpeval{0.5textwidth+0.5textwidth}pt

end{tabular}



end{document}

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:

documentclass{article}

usepackage{geometry}% works when commented out



newcommand{block}{rule{0.5textwidth}{1pt}allowbreakhspace{0pt plus 1sp}}

parindent=0pt



begin{document}

block

block

block

block



end{document}

Another famous case: if you try

setbox0=hbox to 2in{hskip 1in hskip 1in}

you'll get Underfull hbox (badness 10000) because two one inch skips fall 1sp short of two inches.

share|improve this answer

edited 7 hours ago

answered 7 hours ago

egregegreg

745k8919493288

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  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 hspace{0pt plus 1sp} solution would rely on a large enough value of hfuzz—like David Carlisle's raggedright, BTW)
  
  – frougon
  7 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @frougon Always truncation, so hfuzz is not really relevant, because it is about slight overfull, rather than underfull.
  
  – egreg
  6 hours ago
  
  
  

  
  
  
  

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:

documentclass{article}

usepackage{geometry}% works when commented out

usepackage{xfp}



newcommand{block}{rule{fpeval{0.5textwidth}pt}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

blockunpenalty % to avoid the spurious underfull box message



bigskip



begin{tabular}[t]{llll}

Method & half & half + half & text width\

hline

TeX & thedimexpr 0.5textwidthrelax & thedimexpr 0.5textwidth + 0.5textwidthrelax &

thetextwidth \

l3fp & fpeval{0.5textwidth}pt & fpeval{0.5textwidth+0.5textwidth}pt

end{tabular}



end{document}

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:

documentclass{article}

usepackage{geometry}% works when commented out



newcommand{block}{rule{0.5textwidth}{1pt}allowbreakhspace{0pt plus 1sp}}

parindent=0pt



begin{document}

block

block

block

block



end{document}

Another famous case: if you try

setbox0=hbox to 2in{hskip 1in hskip 1in}

you'll get Underfull hbox (badness 10000) because two one inch skips fall 1sp short of two inches.

share|improve this answer

edited 7 hours ago

answered 7 hours ago

egregegreg

745k8919493288

documentclass{article}

usepackage{geometry}% works when commented out

usepackage{xfp}



newcommand{block}{rule{fpeval{0.5textwidth}pt}{1pt}allowbreak}

parindent=0pt



begin{document}

block

block

block

blockunpenalty % to avoid the spurious underfull box message



bigskip



begin{tabular}[t]{llll}

Method & half & half + half & text width\

hline

TeX & thedimexpr 0.5textwidthrelax & thedimexpr 0.5textwidth + 0.5textwidthrelax &

thetextwidth \

l3fp & fpeval{0.5textwidth}pt & fpeval{0.5textwidth+0.5textwidth}pt

end{tabular}



end{document}

documentclass{article}

usepackage{geometry}% works when commented out



newcommand{block}{rule{0.5textwidth}{1pt}allowbreakhspace{0pt plus 1sp}}

parindent=0pt



begin{document}

block

block

block

block



end{document}

setbox0=hbox to 2in{hskip 1in hskip 1in}

share|improve this answer

edited 7 hours ago

answered 7 hours ago

egregegreg

745k8919493288

answered 7 hours ago

egregegreg

745k8919493288

answered 7 hours ago

egregegreg

745k8919493288