[texhax] could someone give me an explanation as to why fontsize fails with an overfull box

[Carlos]

On Sun, Jan 13, 2019 at 01:25:26AM +0100, Reinhard Kotucha wrote:
>On 2019-01-11 at 10:23:03 +0000, Peter Flynn wrote:
>
> > Exactly. If you are setting type in a large size in a narrow
> > measure, you WILL get spacing and hyphenation/justification (H&J)
> > problems.
>
>TeX actually supports narrow columns much better than any other
>program because it considers whole paragraphs.
>
>The main Problem is always the very first line of a paragraph which
>doesn't benefit very much from TeX's advanced algorithms, if at all.
>
>Phil is concerned about the usage of \sloppy.  No LaTeX user is forced
>to use it.  I didn't use it for decades and I never advertised it.
>
>On the other hand, I never hesitated to use \sloppy in letters
>supposed to be sent to the tax office.
>
>Regards,
>  Reinhard
>


Yes, I agree with you and Peter,  but partially with your comment
about the engine. If you were to have a parbox or minipage instead,
everything would be different, but both are to my understanding,
restricted to the page.

One of the best ways that I could probably - not fully - articulate
it, is by the mental representation of a box that should indeed come
last, only after other extraneous elements that are perhaps necessary
but not fully required for its construction, which are fully taking
shape, right after the page dimensions.

And pardon me if I sound naive, and I'm trying not to sound redundant
either, and feel free to correct me here, but if one were to think of
a dash, is normally acceptable that this dash is to be loaded,
regardless of whatever given layout is specified, by having, as
convention currently holds, to have it included before a word. But
where is the common sense at, in writing it [the dash] before it, if
the word is not taking any shape in the end. One would expect that the
word starting with reason entails having human input the same way it
was done in the past. There is no doubt that the norm to write a word
is usually after a dash.  But it makes no difference what the
concomitants are in this time and age, as long as the word is
finalized with the dash preceding it and the page that its being
shipped out reflects it.

The same thing can be said about a box.

In the case of tables and the like, why does the glue does not
supersede a character before the carriage return goes ahead and
spit it all out, has simply left me pondering. 

Take for example the following (albeit unrelated):


\documentclass{article}

\showoutput

\begin{document}

\def\test#1#2{\hbox to 2cm{#1}}
\begin{tabular}{cc}
\test{working}{} &  \test{No} \\
\test{not working}{} &  \test{Yes}{} \\
\end{tabular} 


\end{document}


You'd have:

........\hbox(6.94444+1.94444)x56.9055
.........\OT1/cmr/m/n/10 w
.........\kern-0.27779
.........\OT1/cmr/m/n/10 o
.........\OT1/cmr/m/n/10 r
.........\OT1/cmr/m/n/10 k
.........\OT1/cmr/m/n/10 i
.........\OT1/cmr/m/n/10 n
.........\OT1/cmr/m/n/10 g
........\glue 0.0 plus 1.0fil
........\glue 6.0
.......\glue(\tabskip) 0.0


Here if I were to omit an argument that was predefined and is made up
of "No", tabskip would simply return an error, not because it follows
for tabskip that the argument is done with, but because the tabskip
can't realize that is not even dealing with one [an argument.] to
start with.

Underfull \hbox (badness 2173) detected at line 14
\OT1/cmr/m/n/10 not working

\hbox(6.94444+1.94444)x56.9055, glue set 2.79324
.\OT1/cmr/m/n/10 n
.\OT1/cmr/m/n/10 o
.\OT1/cmr/m/n/10 t
.\glue 3.33333 plus 1.66666 minus 1.11111
.\OT1/cmr/m/n/10 w
.\kern-0.27779
.\OT1/cmr/m/n/10 o
.\OT1/cmr/m/n/10 r
.\OT1/cmr/m/n/10 k
.\OT1/cmr/m/n/10 i
.\OT1/cmr/m/n/10 n
.\OT1/cmr/m/n/10 g

! Extra alignment tab has been changed to \cr.
<recently read> \endtemplate


It would be fallacious to counteract with the no-less factual
sentence, however this may be, that I may have omitted it and failed
to put it in, for it was predefined at an earlier stage, which is
perfectly understandable and quite correct but not acceptable, since I
never included it [the argument], sure, but why does the system does
not circumvent it, is the question that simply leaves me baffled.
Leaves me baffled, for the simple reason that it [system] assumed that
I was done with it, then went ahead and it cleared itself out with an
error message, rather than dealing with the fact that I may have
chosen otherwise not to include it, deliberately, that is. So the
system sees (digests) it, assumes (there is no other word for it in
this case), and spits out an error message instead of correcting it.
Clearly defining an argument is a problem but so does the choice of
the system by processing it. If the arguments are mandatory the system
must somehow process these arguments the same way than optional
arguments are being dealt with- without an error message that is- and
whether or not this argument is omitted once the box starts taking
shape until the page is finally shipped out, and if it is not, then
defining it shouldn't be less of a hassle should the user decide not
to use it.

>From a philosophical point of view, Someone may say, but the word
"mandatory" says it all and it's just that, "mandatory", hence there's
also the word "optional", and what is optional? But I can assure
whoever asks,  that mandatory does not satisfy its maxim, whereas
"optional" can.  Something can be mandatory but nonetheless optional,
and nothing can be both optional and mandatory, or much less optional,
which can also be at times mandatory. I can define the argument with
mandatory arguments, but it's up to a working system to apply it or
omit them accordingly, and I just don't see how it is possible that
this is an outgoing issue with a Turing-complete language.

if on the definition of \def\a\#1#2 the catcode is assumed to have a
mandatory argument, how could it behave as if it were an optional
argument in which it makes no difference whether an argument is
specified?

At this point it seems clear to me, that if the tabular mechanism is
unable to cope with a mandatory argument that was purposely left out,
why isn't the engine taught to deal with it? 

Take care Reinhard, Peter, take care all.



>-- 
>------------------------------------------------------------------
>Reinhard Kotucha                            Phone: +49-511-3373112
>Marschnerstr. 25
>D-30167 Hannover                    mailto:reinhard.kotucha at web.de
>------------------------------------------------------------------