"Underfull" and "Overfull" warnings emitted from Latex.

[burblebee]

We get a ton of "Underfull" and "Overfull" warnings emitted during the Latex build of the spec. What causes them? Can they be fixed?

[godbyk]

The underfull and overfull warnings mean that TeX was unhappy with the spacing in a line—either the line ended up being too short or too long.

For small values of points, this is rarely noticeable to the casual reader and can be ignored. For larger values, there will be white space at the end of a line or a line may overrun its margin.

The amount that you let TeX stretch or shrink the spaces in a line to make it fit the margins can be modified to make TeX more or less lax.

Generally, I just look for overfull or underfull lines that are more than a few points and visually inspect them to see if I need to make any adjustments (e.g., teach TeX how to hyphenate a new word, reword a sentence so it can be typeset more easily, adjust TeX's line breaking parameters to better accommodate that paragraph).

[zygoloid]

@tkoeppe went through and fixed a bunch of these, but I don't think he got through all of the document. It would be good to get this clean before we produce the C++17 IS.

[burblebee]

I tracked down one of the Underfull cases - it's caused by a section name which is too long in xref.tex:
func.searchers.boyer_moore_horspool.creation\quad\ref{func.searchers.boyer_moore_horspool.creation}\\
which ends up spilling over to two lines in the spec:

    func.searchers.boyer_moore_horspool.creation
    20.12.13.3.1

The warning is:

    Underfull \hbox (badness 10000) in paragraph at lines 642--787
    \T1/lmr/m/n/10 (+20) func.searchers.boyer_-moore_-hor-spool.creation

although the actual line is 759.
This long section name also causes the section title to spill over:

    20.12.13.3.1 boyer_moore_horspool_searcher creation functions
                 [func.searchers.boyer_moore_horspool.creation]

I also tracked down an overfull case. The warning is:

    Overfull \hbox (34.36942pt too wide) in paragraph at lines 262--264
    []\T1/lmr/m/n/10 (-20) whether stack is un-wound be-fore call-ing \T1/lmtt/m/n/
    10 std::terminate()

caused by an impldef being too long in exceptions.tex line 1296:
\impldef{whether stack is unwound before calling \tcode{std::terminate()}
and results in an over-long line in the spec:

    whether stack is unwound before calling std::terminate()
            when a noexcept specification is violated,
            429

which causes the xrefs on that page to be only a single column.

It would be good to know what the maximums/minimums are which cause these warnings in various cases so that we could better track the warnings down and avoid them in the future. Is that information available anywhere?

[tkoeppe]

First off: you will never ever be able to fix all the justification problems, since many of them will require wording changes or non-standard hyphenation, and it'd be a futile task, because you'd have to redo the work after every meeting.

What I propose instead is to create a filter on the log to only show those warnings where the excess is large (say over 10pt, or maybe over 3pt later on), and concentrate on those first.

[tkoeppe]

@jensmaurer: If you want to get your hands dirty, here are two typical challenges which you need to be able to answer:

• [exception]p5: The inline code is too long to fit on the line, but cannot reasonably be broken. To fix the presentation, you would probably need to rephrase the text.
  
• Table 29 (Allocator requirements), the "default" entry for max_size. The tabular presentation of requirements is just totally awful, and I have no idea how to fix this other than by getting rid of the tables altogether (I have a proposal for that).
  

(To be clear, my personal position is that we should leave both of those cases alone and instead exercise discretion. We should only fix those instances of overfull boxes that are obviously disruptive.)

[jensmaurer]

@tkoeppe: We can certainly fix the overlong stable names; those will continue to bite us otherwise. For the requirements tables, we can either abandon them or ignore the problem. For [exception]p5 in particular, I'll send a pull request.