Resolve some 'Overfull \hbox' warnings. #1068
Conversation
| @@ -6338,7 +6338,7 @@ | |||
| \pnum | |||
| \requires | |||
| \tcode{is_assignable_v<mapped_type\&, M\&\&>} shall be \tcode{true}. | |||
| \tcode{value_type} shall be \tcode{EmplaceConstructible} into \tcode{map} | |||
| \tcode{value_type} shall be \tcode{Emplace\-Constructible} into \tcode{map} | |||
There was a problem hiding this comment.
Can you try adding EmplaceConstructible to the global hyphenation hints (in std.tex) and see if that works? If the issue is just that it's an unknown word, then that's a more sustainable approach.
There was a problem hiding this comment.
I have just tried using this and get no changes (according to diffpdf):
\hyphenation{tem-plate ex-am-ple name-space name-spaces emplace-constructible copy-constructible less-than-comparable in-put-it-er-a-tor out-put-it-er-a-tor for-ward-iter-a-tor rand-om-acc-ess-iter-a-tor}
There was a problem hiding this comment.
I am unable to get LaTeX to hyphenate EmplaceConstructible using \hyphenation. Maybe because the word has a capital letter in the middle.
There was a problem hiding this comment.
I think it may be because the text is inside a \tcode. We could probably also change that somehow. The hyphenat package does something similar.
There was a problem hiding this comment.
So, what's the next step here? Adding the manual hyphenation fixes the non-hyphenation of the term in the four places where it's an "overfull \hbox" problem.
There was a problem hiding this comment.
Yes, keep it manual for now. It's what we've been doing and it's an OK solution. We can research better solutions offline. (The only problem with manual fixes is that they are very brittle when the text changes and may need to become stale or need refixing. But that's what we're here for.)
There was a problem hiding this comment.
Ah, I just tried, and we probably really don't want to monkey with global tcode, because then we'd end up hyphenating things like 1.2e-34. :-)
There was a problem hiding this comment.
regarding "very brittle": We have lots of paragraphs, and only if this particular paragraph changes again in the future do we need to reconsider the manual hyphenation.
| ``implicit int'' rule of C is no longer supported.} | ||
| \begin{note} | ||
| A \grammarterm{nodeclspec-function-declaration} can only be used in a | ||
| \grammarterm{template-declaration}~(Clause~\ref{temp}), | ||
| \grammarterm{explicit-instantiation}~(\ref{temp.explicit}), or | ||
| \grammarterm{explicit-instan\-tiation}~(\ref{temp.explicit}), or |
There was a problem hiding this comment.
My more natural reaction would be to remove the non-breaking space first. I always thought that those were tenuous at best; there's very little reason to prevent a break before the reference. Either the reference fits on the same line and all is well, or it doesn't, and then that's still by far the best place to break compared to anywhere else.
There was a problem hiding this comment.
Done, although I notice that we do usually attach cross-references to the preceding term.
There was a problem hiding this comment.
Right, but as I said that's rather strange if it requires hyphenation in the previous term. I think the non-breaking space is only an approximation, and what we really want is a "discouraging" space that says "please try not to break here if possible".
But surely it's much better to break at a real space than introduce awkward hyphenation. What do you think? In real-world publishing you would probably try to rephrase the text to achieve the desired presentation, but given the constant changes we are making, I would strongly prefer the simple and maintainable solution that doesn't require manual intervention.
There was a problem hiding this comment.
Fine with me. As I said above, the newest update has the "make it breaking whitespace" change.
|
The results look very, very good to me. |
| @@ -1941,7 +1941,8 @@ | |||
| template <size_t I, class... Types> | |||
| constexpr tuple_element_t<I, tuple<Types...>>&& get(tuple<Types...>&& t) noexcept; // Note A | |||
| template <size_t I, class... Types> | |||
| constexpr tuple_element_t<I, tuple<Types...>> const& get(const tuple<Types...>& t) noexcept; // Note B | |||
| constexpr tuple_element_t<I, tuple<Types...>> const& | |||
There was a problem hiding this comment.
Just for visual harmony, would it be possible to break all three declarations in the same way?
There was a problem hiding this comment.
I don't think this is obviously an improvement, but done anyway.
| @@ -13769,7 +13779,7 @@ | |||
| \requires \tcode{F} shall be \tcode{CopyConstructible}. | |||
|
|
|||
| \pnum | |||
| \remarks This constructor shall not participate in overload resolution unless | |||
| \remarks This constructor template shall not participate in overload resolution unless | |||
| @@ -457,7 +457,7 @@ | |||
| { | |||
| \begin{LongTable} | |||
| {#1}{#2} | |||
| {x{.35\hsize}x{.28\hsize}x{.30\hsize}} | |||
| {x{.35\hsize}x{.28\hsize}x{.29\hsize}} | |||
| } | |||
There was a problem hiding this comment.
Interesting. I wonder were those original values came from. I suppose they were too big because they didn't account for cell padding?
There was a problem hiding this comment.
That's my guess, or disregard of inter-cell spacing.
|
I agree, a very nice change. I wonder if we get to merge it before the motions; will check with @zygoloid. |
Partially addresses cplusplus#693.
Partially addresses #693.