On Mon, 6 Jul 1998, Werner Icking wrote:
> % When trying to introduce rests within triolets into PMX I generated
> % a MusiXTeX source which produced "Underfull hbox". The PMX input
> % was "c45x3 e g" instead of r4x3 e g".
> %
> % Here's the source which reports "Underfull hbox":
> %\input musixtex
> \hsize=100pt\elemskip1pt\afterruleskip1pt\beforeruleskip0pt
> \newcount\nick
> \def\dsibl#1{\nick=#1\ds}%
> \def\dsasibl{\let\iblsav\ibl\let\qbsav\qb%
> \def\ibl##1##2##3{\zcharnote{##2}{~}\dsibl{##3}\let\ibl\iblsav}%
> \def\qb##1##2{\let\qb\qbsav}}%
> \def\iblqb#1#2{\ibl#1{#2}{\nick}\qbsav#1{#2}}%
> \def\iblasqb{\let\qbsav\qb%
> \def\qb##1##2{\iblqb##1##2\let\qb\qbsav}}%
> \startmuflex\startpiece
> \NOTes\dsasibl\ibl1{'d}1\qb1c\iblasqb\qb1e\tbl1\qb1g\en\endpiece
> \vfill\eject\endmuflex\bye
>
> % The underfull hbox gets smaller if I increase elemskip; it disappears
> % for \elemskip=4pt or bigger.
> %
> % Any hint what's going wrong? Rounding problems in musixflx?
> %
> % Thanks in advance -- Werner
> %
> % PS: \elemskip=1pt is used by PMX to suppress "Overfull hbox"-message
> % during MusiXTeX phase 1. It shouldn't matter for the music output
> % because PMX breaks the lines using \xbar and \alaligne by itself.
>
Greetings Werner!
This is an exceeding subtle problem but fortunately the answer is simple:
First the answer:
The definition line...
> \def\iblqb#1#2{\ibl#1{#2}{\nick}\qbsav#1{#2}}%
should include \the before \nick, as in:
> \def\iblqb#1#2{\ibl#1{#2}{\the\nick}\qbsav#1{#2}}%
Those who have suffered through the "dangerous bends" of TeX will recall
that counters are treated differently in macro expansion than simple tokens.
Consequently, what has to be produced is not just a reference to the counter,
but it's stored value.
The problem is, that deep in the macro expansions, the reference to
{\nick} is at one point expanded to {\nick }, and is later accepted as
an argument to another macro with the trailing space attached. Because
it is used in a horizontal mode context (I think), the trailing space
gets put into the output, and becomes one of those "stray spaces" we
have always been warned about. I think this occurs because \nick is
a counter, not a simple token string.
The above fix makes the Underfull hbox go away, but I cannot tell whether
it actually produces what you want. I suppose if it still doesn't work
one might try:
> \def\iblqb#1#2{\ibl#1{#2}\expandafter{\the\nick}\qbsav#1{#2}}%
:-)
Hints To MusixTexers on How to Find Strange Output Bugs:
(A few ideas gathered on this bug hunt.)
You can get TeX to tell you EVERYTHING (more than you want to know)
about what is going on, and what is going out....
On some line of your .tex input file, enter the line
\tracingall
Thereafter, EVERYTHING is reported to the log file! This is recommended
only for very short examples, (like Werner's above), and you should expect
an immense log file to result. However, you can also see every macro
expansion, every output character produced, and an analysis of every output
box. (A good background reading of Knuth's "The TexBook" would also
be most beneficial. :-).
However, suppose your job is introducing an unwanted blank space. This
trick will show you when that blank space is output. For Werner's
example, it came to attention like this:
----- excerpt from the log file with \tracingall active ....
\s@uite ->
{\else}
{\count30}
{blank space } <---- Here is where the blank space appears.
\C@ib #1->\max@n@v \nin@ \min@n@v {-\nin@ }\global \b@p \n@v \getcurpos \global
\b@x \y@v \b@z #14.333\interbeam \advance \b@z \altportee \pl@base \global \ad
vance \b@z \y@i
#1<--
-------end excerpt
All you have to do for a very large file, is open it in the editor and
search for "blank space", and you will prove that one is being processed.
Now, where it comes from, and why it is produced is another story...
When a trace is constructed, every macro is shown expanded, followed by
the arguments it is accepting. Then line-by-line it shows what macros
or TeX words were executed. When it finds another macro, it expands that
too, right there, and continues deeper into the details. So, although
we see the {blank space } above, we only know that something earlier,
maybe several layers out produced it, and we are just now getting
around to processing it.
For a detailed, multi-level package like MusixTex, this can appear to be
very messy, and the fainthearted would probably give up after several pages
of expansion. However, Fear Not! This answer is probably there somewhere.
In this case, it was only necessary to page back from the point where
the blank is introduced, to observe a strange phenomenon...
This macro expansion report catches the watchful eye, because one notices
that a space is inserted after \nick (for no apparent reason), but there
is NOT a space after other things like #2, etc. (This is more apparent
after you have stared at many example lines in the log file... :-)
\iblqb #1#2->\ibl #1{#2}{\nick }\qbsav #1{#2}
#1<-1
#2<-e
At first, you might think that the space after \nick will just get absorbed.
(A lot of times, spaces don't matter...!) However, later when the macro
\i@bl is executed, one can see exactly what is accepted in its argument
list as a result of that space being introduced there..
\i@bl #1#2->\ifnum \b@n =\z@ \else \C@tb \t@bbl \lthick \fi \global \b@n \@ne \
inhgetn@i #1\relax \n@v #2 \C@ib -
#1<-e
#2<-\nick <---- My editor shows that there is a trailing space here...
So, now we have found the culprit, but WHY is the space appearing. It is
NOT in the original input. It was apparently added during the macro
expansion, and now gets into the output, not by any action on our part.
This is where one needs to recall that counters are a little different than
other TeX data objects... (I don't know why, so I won't say more...)
However, if you want the VALUE of some TeX object, you precede it with \the
and the result is provided. In this case \the\nick seems to eat the
trailing space (just like you would expect) and make the value usable
in the subsequent macro... (I won't guarantee anything here, cause
I'm over my head already :-)... Maybe it isn't really doing what Werner
wants... But we did make the underfull hbox go away. Yea!)
Another interesting thing you can glean from the log files, (using
\tracingall) is to observe just what is shipped out for your page.
This helps because you can double check on just what is "taking up
space." This is how I noticed that there was some unexplained glob
of glue in the output...
I will again use Werner's example to illustrate this process. The following
will appear at the end of the log file (for a very short example).
I will annotate, and this will probably look better with a fixed width
font on your mail viewer...
Completed box being shipped out [1] < Find this point in the log
\vbox(794.45078+2.5)x100.0 < Each Tex BOX is reported.
.\vbox(782.45078+0.0)x100.0, glue set 732.45078fill
..\glue 0.0 plus 1.0fil minus 1.0fil < The DOTS indicate NESTING.
..\glue(\topskip) 0.0
[my break... read \hbox(height+)xWidth... The next box is 100 units wide.]
..\hbox(50.0+0.0)x100.0, glue set 63.26672fil < This is the STAFF box.
...\hbox(0.0+0.0)x0.0
...\hbox(50.0+0.0)x0.0
....\hbox(0.0+0.0)x0.0, glue set - 100.0fil, shifted -15.0
.....\vbox(0.0+0.0)x100.0, glue set - 24.8fil
......\glue 0.0 plus 1.0fil minus 1.0fil
......\kern 5.0
......\kern -0.4
......\rule(0.4+0.0)x100.0 < These are the 5 lines of the staff
......\kern 5.0
......\kern -0.4
......\rule(0.4+0.0)x100.0 < Second line of staff...
......\kern 5.0
......\kern -0.4
......\rule(0.4+0.0)x100.0 < Third line, etc...
......\kern 5.0
......\kern -0.4
......\rule(0.4+0.0)x100.0
......\kern 5.0
......\kern -0.4
......\rule(0.4+0.0)x100.0
......\kern -0.2
.....\glue 0.0 plus 1.0fil minus 1.0fil
....\hbox(20.0+0.2)x0.0, glue set - 0.4fil, shifted -15.0
.....\rule(20.0+0.2)x0.4
.....\glue 0.0 plus 1.0fil minus 1.0fil
....\hbox(20.0+0.0)x0.0, shifted -30.0
.....\rule(20.0+*)x0.0
....\glue 0.0 plus 1.0fil minus 1.0fil
...\hbox(0.0+0.0)x0.0, shifted -25.0 <-- Here's our first BOX
[note that we are interested in stuff at the "..." level, because
these correspond the spacing commands written to the .MX1 file.
Also notce that the above box is 0.0 WIDE, that is it contributes NOTHING
to the overall width, just like the manual says... Imagine, that this
box will be filled with clefs, signs, notes, whatever, and Tex believes
that it has NO Width... That's how they do that! ]
....\hbox(0.0+0.0)x0.0, glue set - 6.66666fil <- This is INSIDE the "..." box
.....\glue 0.0 plus 1.0fil minus 1.0fil
.....\vbox(0.0+0.0)x0.0
......\hbox(0.0+0.0)x0.0
.......\glue 0.0 plus 1.0fil minus 1.0fil
.......\glue 0.0 plus 1.0fil minus 1.0fil
.....\penalty 10000
.....\glue 3.33333 plus 1.66666 minus 1.11111
.....\penalty 10000
.....\glue 3.33333 plus 1.66666 minus 1.11111
....\glue 0.0 plus 1.0fil minus 1.0fil
...\hbox(27.5+7.5)x0.0, glue set - 15.99998fil, shifted -15.0
....\hbox(27.5+7.5)x15.99998
.....\hbox(22.5+12.5)x15.99998, shifted -5.0
......\musictwenty G <--- This is our CLEF sign....
....\glue 0.0 plus 1.0fil minus 1.0fil <-- Ignore (for now) .... or greater
...\kern 15.99998 <-- And here is the CLEF skip, which is also written
to the .MX1 file.
[Note that the \kern lines (at level ...) are what we are looking for.
The general rule is, ...\hboxes should have 0.0 width, all GLUE at this
level should have 0.0 dimension, and only the ...\kern lines should
have substantial space.]
[Here's another \hbox at level ..., also has 0.0 WIDTH - GOOD!]
...\hbox(0.0+0.0)x0.0, glue set - 1.99997fil, shifted -15.0
....\hbox(0.0+0.0)x1.99997
.....\kern 0.99998
.....\kern 0.99998
....\glue 0.0 plus 1.0fil minus 1.0fil
...\kern 1.99997 <-- Here is the SIGN skip, which also goes to .MX1
...\glue 0.0 plus 1.0 minus 1.0 <-- Notice that this glue has 0.0 Width
...\kern 0.0 <-- This is the space for the before or afterrule skip...
...\hbox(25.0+0.0)x0.0, glue set - 18.33333fil, shifted -15.0 <- More of ours
....\hbox(0.0+0.0)x0.0, glue set - 3.33333fil, shifted -15.0
.....\penalty 10000
.....\glue 3.33333 plus 1.66666 minus 1.11111 <- I give up, I can't explain
.....\glue 0.0 plus 1.0fil minus 1.0fil
....\hbox(16.25+0.0)x5.0 <-- At level ...., this is our first element
of music entered in the line, probably 5.0 is ONE elemskip. (?)
.....\hbox(16.25+0.0)x5.0, glue set 5.0fil
......\musictwenty ? <--- Ah, real music.... The \ds (I believe)
......\glue 0.0 plus 1.0fil minus 1.0fil
....\glue 3.33333 plus 1.66666 minus 1.11111 <---BRIGHT LIGHTS!!!
[Whoa... Now here's a funny glob of glue... This is a hint there
is something more going on than meets the eye. Observe...
It is not in the Clef or Sign area (where stranger things are seen,
and are still unexplained)... It is right here in the list of
music output things... And, (hint) it doesn't come after
other things just like this later, but we can't explain why it is
here, and not later... This is \glue that has a width NOT 0.0,
so it is probably NOT getting counted in the width written out
for Musixflx to use. This is why we go back to the \tracingall
log looking for something that causes GLUE at some point AFTER
the \ds (rest) character is output. :-) ] [And that,... fellow
MusiXTeXer's... is how the space was found in this case :-)]
....\kern 0.0
....\rule(17.5+-1.25128)x0.4
....\kern -0.4
....\kern 0.0
....\hbox(2.5+2.5)x5.0, glue set 5.0fil, shifted -17.5
.....\musictwenty ^^G <-- More real music characters going out.
.....\glue 0.0 plus 1.0fil minus 1.0fil
....\hbox(1.32129+0.0)x0.0, glue set - 4.99997fil
.....\glue 0.0 plus 1.0fil minus 1.0fil
.....\hbox(0.0+0.0)x3.99998, shifted -1.25128
......\musictwenty ^^81
.....\kern -2.6
[Remember that all this stuff .... or greater, is inside imaginary boxes
that TeX believes have NO width. ]
.....\hbox(0.0+0.0)x3.99998, shifted -1.32129
......\musictwenty ^^81
.....\kern -0.4
....\kern 0.0
....\rule(22.5+-1.50128)x0.4
....\kern -0.4
....\kern 0.0
....\hbox(2.5+2.5)x5.0, glue set 5.0fil, shifted -22.5
.....\musictwenty ^^G
.....\glue 0.0 plus 1.0fil minus 1.0fil
....\glue 0.0 plus 1.0fil minus 1.0fil
...\kern 18.33333 <-- Here is the total width of stuff inside the last
hbox, and this spacing entry is controlled carefully by MusixTex. It
is written to the .MX1 file as the scalable space for this bar. However,
in this case, the .MX1 file was NOT told about the \glue 3.33333 we
observed above, so it does not adjust for it, and comes out wrong.]
...\kern 0.0
...\hbox(20.0+0.2)x0.0, glue set - 0.4fil, shifted -15.0
....\rule(20.0+0.2)x0.4
....\glue 0.0 plus 1.0fil minus 1.0fil
...\kern 0.4
...\penalty 10000
...\glue(\parfillskip) 0.0 plus 1.0fil < Good, this glue has no dimensions.
...\glue(\rightskip) 0.0
..\glue 0.0 plus 1.0fill
..\glue 0.0 plus 1.0fil minus 1.0fil
.\glue(\baselineskip) 4.5
.\hbox(7.5+2.5)x100.0, glue set 80.55553fil
..\glue 3.33333 plus 1.66666 minus 1.11111
..\tensl ( <- Stuff that appears at the bottom of the page.
..\tensl )
..\glue 3.33333 plus 1.66666 minus 1.11111 <More space glue at page bottom
..\glue 0.0 plus 1.0fil minus 1.0fil
..\tensl 1 < -- The page number...
Now, wasn't that FUN!
Okay, (maybe not) but seriously, you can learn a lot about your TeX job
by just asking TeX to show you everything.... Here are a few specific
commands (from the TeXBook)
\tracingmacros=1 Shows just the macros expanded.
\tracingoutput=1 Shows the contents of each box shipped out.
\showboxbredth=n How many items in a box are shown (default 5)
\showboxdepth=n The deepest level to go (default 3)
\tracingonline=1 All diagnostics go to terminal as well as log file
\tracingcommands=1 Show each command executed
\tracingall (No value, turns all Tracing command TRUE)
To turn any tracing command off use value =0
To see the type and value of anything during a run, enter
\show item... Where item is a tex word, such as \ibl, e.g.
\show\ibl
When this is encountered, the job will pause to show you the item
requested, and you can simply hit enter to continue the job... (Great
for debugging macros!)
To see the value of things, enter \showthe... as in
\showthe\nick
I hope these hints have been helpful to someone. :-)... I suspect
it is always possible to write TeX code so layered and contorted that
nobody else can figure it out. However, as time passes, I continue to
grow in appreciation for the genius and skill manifested in the MusiXTeX
package (which I use), and I am sure, is also in its relatives packages!
Here is another big THANNS to all its authors and contributors!
Regards,
Joel Hunsberger
[EMAIL PROTECTED]
(Part Time Musician, too late smart :-)
