Published: 17th February 2013M / 6 Rabiulakhir 1434H, Su.
Updated:
Assalamualaikum warahmatullah. Inspired by this statement:
... I would never accept a final PDF where there's some Overfull \hbox.... I decided to solve all the warnings and badboxes in my thesis although there is no problem at all to produce a PDF output (PDFLaTeX).
Source: Do I have to care about bad boxes?
In answer by egreg
http://tex.stackexchange.com/a/50838
Starting with about 0 errors, 31 warnings, 212 badboxes (see Pic 1), I've managed to trim them down to 0 errors, 0 warnings, 3 badboxes (see Pic 2). The remaining badboxes are in the generated bibliography which I don't know how to solve.
Badboxes, according to egreg:
1. Overfull \hbox messages tell you that some line sticks out over the right margin;
2. Underfull \hbox messages tell you that some line is poorly typeset (or that you've improperly used \\ to leave a vertical space (for example, typing two \\ in a row);
3. Underfull \vbox messages usually tell you that a page is poorly typeset.
Source: Do I have to care about bad boxes?
In answer by egreg
http://tex.stackexchange.com/a/50838
Read the answers here to know a little bit more about the badboxes:
What are underfull hboxes and vboxes and how can I get rid of them?
http://tex.stackexchange.com/questions/138/what-are-underfull-hboxes-and-vboxes-and-how-can-i-get-rid-of-them
About the badness number:
Similar are \hbadness and vbadness which are a measure of how bad a box is, typically how much white space has had to be stretched. the exact number is not usually that relevant but 0 is good and 10000 is infinitely bad (TeX's badness calculation arbitrarily forces any very bad boxes to this amount).
Source: Do I have to care about bad boxes?
In answer by David Carlisle
http://tex.stackexchange.com/a/50850
My suggestion is to solve the warnings as much as possible first, and then solve the badboxes.
Part A: The draft
As suggested by Otis:
If you use draft mode (\documentclass[draft]{article}) you can see black lines on the side of your document where there is overfull hbox badness. This is a convenient way to find and fix these errors. – Otis Jul 26 '10 at 19:54
Source: What does “overfull hbox” mean?
In comment by Otis
http://tex.stackexchange.com/questions/35/what-does-overfull-hbox-mean#comment21_39
1. In the preamble, add the term (see Pic 3):
draft...in the \documentclass.
2. Compile the document by Build > Compile > PDFLaTeX for the first compile. See Pic 4.
The following compiles can use the Build > QuickBuild. See Pic 5.
Don't worry when the figures in the output document are substituted with a thin black-bordered hollow rectangle, see Pic 6. Compare Pic 6 with Pic 7.
If you seem to get errors when previously there weren't any errors, try running this step (QuickBuild compile) a few times. Try about 3 to 4 times or more until you get about the same amount of warnings and badboxes as you had before changing the document into a draft.
3. Make the necessary corrections to solve the warnings and badboxes. Refer to Part B to Part G in this post.
4. As this "drafting" step is temporary, the draft term added in Step 1 should be removed after the required corrections are completed in order to return to the 'print'/'real' mode.
Part B: "Shell escape feature is not enabled."
One of the warnings that might arise in Kile from Step 2 is the "Shell escape feature is not enabled." warning. See Pic 8.
By solving the shell escape warning, this deducted 1 warning for me. See Pic 9.
See also:
Development of LaTeX frontend kile. () > eps && pdf
http://comments.gmane.org/gmane.comp.kde.devel.kile/1410
5. Go to Settings > Configure Kile... . See Pic 10.
6. In the Configure - Kile dialog, see Pic 11,
in the leftmost column, go to Tools > Build.
Then under the Select a tool column, select PDFLaTeX.
Go to the General tab. In the Options: field, change from this:
-interaction=nonstopmode '%source'
... to this:
-interaction=nonstopmode -shell-escape '%source'
Source: Forward & Reverse DVI with multiple file document
In reply by dj_bridges
http://www.latex-community.org/viewtopic.php?f=20&t=3380#p13225
Then click the OK button.
7. Compile the document. Refer to Step 2.
Part C: `!h' float specifier changed to `!ht'.
Fixing the "`!h' float specifier changed to `!ht'." warning (see Pic 12) should reduce the number of warnings.
The float specifiers:
h means here allowed,
t means top,
b means bottom,
p means on a float-page,
! means try harder! to place it earlier.
Source: `h' float specifier changed to `ht' warning when not attempting to specify a float
In answer by Stefan Kottwitz
http://tex.stackexchange.com/a/1527
Usually h is too strict. This way you don't allow top, bottom or page placement. Use at least ht instead, or relax it to htbp or even !htbp if you like. If you really need it to be exactly "here", use the H option together with the float package. There are further ways. But adding placement options is usually fine.
Source: LaTeX Warning About Height, \hbox, and \vbox, and ht
In answer by Stefan Kottwitz
http://tex.stackexchange.com/a/6983
Read more about floats, here:
LaTeX/Floats, Figures and Captions > Floats
http://en.wikibooks.org/wiki/LaTeX/Floats,_Figures_and_Captions#Floats
8. Check the float specifiers in the *.tex files.
Change from [!h] or [h!]
to [!ht] or [!hb] or any specifier combination you want depending on your needs. See Pic 13 and Pic 15.
9. Compile the document. Refer to Step 2.
My suggestion is: change the float specifier for one figure or table at a time then compile. If the number of warning goes down, only then proceed to the next figure or table.
Part D: "No positions in optional float specifier."
Fixing the "No positions in optional float specifier." warning (see Pic 14) should reduce the number of warnings.
I use sidewaysfigure and sidewaystable. Previously i didn't use the float specifier for the sideways because if I used an unsuitable specifier, LaTeX will lump all the figures at the end of the chapter instead of placing them where I have placed them throughout the chapter.
If you put in a suitable specifier, the warning goes away and the object (figure/ table) stays where you want it to be.
10. For the sidewaysfigure or sidewaystable, instead of using [!h] or [!ht], I used [!p]. See Pic 15.
11. Compile the document. Refer to Step 2.
My suggestion is: change the float specifier for one figure or table at a time then compile. If the number of warning goes down, only then proceed to the next figure or table.
The draft for Pic 15 is shown in Pic 16, and the "real" page is shown in Pic 17.
Part E: "Font shape `OT1/cmr/bx/sc' undefined(Font) using `OT1/cmr/bx/n' instead on input line ##."
Fixing the "Font shape `OT1/cmr/bx/sc' undefined(Font) using `OT1/cmr/bx/n' instead on input line ##." warning (see Pic 18) should reduce the number of warnings.
About the warning:
You did nothing wrong. TeX tells you that it does not have Small Caps bold Computer Modern font, so it switches to bold normal font. This is a design decision by font author (Knuth) not to have this variant; you may try to find fonts that have bold small caps (not that I know of such) or to fake the effect using uppercase.
Actually your line is already in uppercase, so I wonder whether you really need small caps: usually people use small caps with lowercase letters, with \textsc{\MakeLowercase{...}}
Source: A problem with \textsc
In answer by Boris
http://tex.stackexchange.com/a/37620
12. There are 2 solutions I can think of, attemped, and worked for me:
A. The solution I used in my thesis is to remove the Small Caps code, \textsc and simply type in all capitals. See Pic 19.
B. Another way is as Boris mentioned. The code is shown in Pic 19 and the output is shown in Pic 20.
13. Compile the document. Refer to Step 2.
Part F: "Overfull \hbox (##pt too wide) in paragraph"
Fixing the "Overfull \hbox (##pt too wide) in paragraph" badbox (see Pic 21) should reduce the number of badboxes.
About fixing the Overfull \hbox:
but what can be done about Overfull \hbox? – alfC Apr 5 at 18:10
http://tex.stackexchange.com/questions/50830/do-i-have-to-care-about-bad-boxes#comment105354_50838
@alfC Some small text editing usually solves the problem. I use to say that very rarely the first or even the fourth version of a text has so polished a prose that it's become untouchable. :) – egreg Apr 5 at 19:40
http://tex.stackexchange.com/questions/50830/do-i-have-to-care-about-bad-boxes#comment105386_50838
small text editing means changing the choice of words? (just asking). – alfC Apr 6 at 7:08
http://tex.stackexchange.com/questions/50830/do-i-have-to-care-about-bad-boxes#comment105496_50838
@alfC That's one of the possibilities. In some case just altering the word order can help; adding or removing a "that"; applying a hyphenation that TeX wouldn't have chosen; … – egreg Apr 6 at 8:58
http://tex.stackexchange.com/questions/50830/do-i-have-to-care-about-bad-boxes#comment105507_50838
Source: Do I have to care about bad boxes?
In comments to egreg's answer
http://tex.stackexchange.com/a/50838
14. Scroll in the drafted output (refer to Part A) to look for a thick black vertical (with respect to the text direction) line. These thick lines mark the items that exceed the right-hand margin.
See Pic 22 for an example of an overfull figure,
Pic 23 for an overfull sidewaysfigure,
Pic 24 for an overfull table, and
Pic 25 for an overfull text.
15. When you see the thick line, go the related *.tex file.
Note that these are only suggestions of what-to-do to overcome the badboxes. Adjust accordingly to suit your needs.
A. If it's a figure, scale-down the figure.
B. If it's a table, adjust the cell size, or font size, or wording.
C. If it's texts, adjust the horizontal space for the text, or change the wording, or add hyphenation.
16. Compile the document. Refer to Step 2.
Part G: Fixing the Underfull \hbox badboxes
This fix was inspired by this post:
You should rarely need to use \\ in documents apart from its use in alignments (where it is a macro based on the \cr primitive), and you should rarely need \par in documents as a blank line should suffice.
Source: When to use \par and when \\
In reply by David Carlisle
http://tex.stackexchange.com/a/82666
The usual mistakes:
The usual mistake is *ending* a paragraph with \\
As I did just above -- with a blank line or \par following after \\. People do this to increase the paragraph separation, when they should instead set \parskip. The underfull box arises because the paragraph-fill space (\parfillskip) is discarded when a totally empty line occurs.
If you *begin* a paragraph with \\ (\\ after a blank line) LaTeX complains explicitly.
Source: Underfull \hbox (badness 10000) warning
In reply by Donald Arseneau
https://groups.google.com/d/msg/comp.text.tex/5LZ06meo80s/sm3UwYPAYGYJ
About the \\ (double backslash):
The intent of \\ is to fill with whitespace and produce a linebreak. Maybe you are thinking of \linebreak rather than \\ (or \newline).
Source: Underfull \hbox (badness 10000) warning
In reply by Donald Arseneau
https://groups.google.com/d/msg/comp.text.tex/5LZ06meo80s/sm3UwYPAYGYJ
Initially I used \\ at the end of paragraphs like in Pic 26.
Then I used \vspace and \par at the beginning of paragraphs like in Pic 27.
In the end I used \vspace and blank lines. I didn't use \setlength{\parskip} because it upsets the spacing-between-paragraphs of the whole document whereas I want it to effect only the chapters; fine-writing the template might be able to make it work as needed. So to obtain the spacing-between-paragraphs, I used \vspace{8.0 mm}. The extra blank lines are for my own readability.
17. In the *.tex file, I deleted all \\ and \par and rearranged \vspace{8.0 mm} to be above paragraphs. See Pic 28.
Note that I use \\ in a list or any text that has no blank lines in between. See Pic 29.
18. Compile the document. Refer to Step 2.
The output of Pic 28 is shown in Pic 30.
Alhamdulillah. Wassalam.
And how to Fix the Underfull \vbox badboxes?
ReplyDeleteIt's an extremely foolish recommendation to blindly enable shell escaping whenever possible. This feature is pretty dangerous: like VBA macros in M$ Office documents, it may be used to include malware in documents or packages. See my example there, it's pretty easy: https://qr.ae/TLn5bv Such code may occassionally reveal in any .sty/.tex file, especially if you download them somewhere outside of CTAN and TeXlive. Whoever knows when some troll or misanthrope would publish a TeX virus...
ReplyDeleteThere are some packages, like minted, that need -shell-escape for legitimate reasons: to call some external tools (and their instructions will contain a requirement to install them first anyway). But as a rule of thumb, you should be alarmed if something needs shell-escaping, and check why before enabling it.
In the case shown on the screenshot in this post, the external epstopdf converter is needed because some illustrations included in the document are in EPS format. This is an anti-pattern: modern LaTeX compilers, like pdflatex and xelatex, are generating PDF rather than raw PostScript, and they just can't include EPS images: this is why convertation is need. You really should convert all graphics in PDF, PNG or JPG format before including in a LaTeX document. Unlike your stereotypes may tell, PDF is not only a format for printed documents, but also a good container for vector graphics, so you may convert static vector graphics from any other format with no any loss. Besides of eliminating the ugly epstopdf quirk, this also will speed up the document build process.
It's an extremely foolish advice to blindly enable shell-escaping whenever possible. This feature is dangerous: like VBA macros in M$ office documents, it allows to include malware in LaTeX documents. See my example, it's pretty easy: https://qr.ae/TLn5bv Such code may occasionally reveal in any .sty/.tex files, especially if you download them from somewhere outside of CTAN and TeXlive. Whoever knows if some troll or misanthrope would publish a TeX virus...
ReplyDeleteSome packages, like minted, need -shell-escape for legitimate reasons: to call some external tools. But their instructions will include an instruction to install those tools first anyway. As a rule of thumb, you should be alarmed if something needs shell-escaping, and check why before enabling it.
In the case shown in this post, shell-escaping is needed because some illustrations included in the document are in EPS format. This is an anti-pattern: modern LaTeX compilers, like pdflatex and xelatex, generate PDF directly rather than raw PostScript, thus they can't just include an EPS image and need a converter. You really should manually convert any graphics to PDF, PNG or JPG format before including in a document. Unlike your stereotypes may tell, PDF is not only for printable documents, it's also a great container for any static vector graphics, so you can convert other vector formats in PDF with no any loss with tools like ImageMagick or Inkscape. This will not only eliminate the need in ugly epstopdf quirk, but also speed up the document build process.