I am running TeX and friends on a Linux box and get the following error
message from dvips: what do you make of it?
This is dvips(k) 5.85 Copyright 1999 Radical Eye Software
(www.radicaleye.com) ' TeX output 2000.04.20:1116' -> cyclop.ps
dvips: ! error while unpacking; more bits than required
Is dvips trying to unpack its lunch box on my workstation? No seriously
now: Again, the TeX package is the teTeX web2c package, and on my dos box
there is no troubles using the emTeX package. The best I have been able to
do is to track the error down to a single figure drawn by metapost. Since
that same metapost code is used in anothe paper of mine, and there it
causes no troubles I am at a bit of a loss for what to guess the problem
is.
Any suggestins?
Larry Smith
-tom
On Thu, 20 Apr 2000, Darrel Hankerson wrote:
> Again, the TeX package is the teTeX web2c package, and on my dos box
> there is no troubles using the emTeX package. The best I have been able to
> do is to track the error down to a single figure drawn by metapost. Since
> that same metapost code is used in anothe paper of mine, and there it
> causes no troubles I am at a bit of a loss for what to guess the problem
>
> Wild guess: the figure is compressed with gzip or some other tool and
> has extra bits at the end. If so, you could test with the expanded
> version of the file.
>
> Wild guess #2: is this a dos-vs-unix-eol problem?
>
> --Darrel Hankerson han...@mail.auburn.edu
>
>
Dear Darrel,
I think the answer is no on both counts. Since the project is a book that
is already behind schedual I have spent the last 24 hours tracking things
down: believe me this was a joyoeus experience. I spent a lot of time on
the wrong track, figuring it was a check sum error in one of the
PostScript fonts that I was using, or a round off incompatability in the
floating point conversion routines in MetaPost and dvips But no: the
error, as far as I understand it, is more mundane.
In the file called bookname.mp, where the figures for the book are "drawn"
in MetaPost code, right at the beginning of the file was (!) the sequence
defaultfont = "pgararm";
The font pgararm is a "virtual" font based on a PostScript implementation
of Garamond that I bought. This is the main text font in the book. Now,
here come the convoluted problems: this virtual font refers to a bunch of
actual fonts of course, but being "virtual" has no entry in any of the
.map files used by dvips. In the guts of the MetaPost code for the
diagrams one has the sequence of instructions:
beginfig(7);
%% beginfig(2);
draw (0,0)--(-72,0);
draw (0,72)--(0,0);
draw (0,0)--(-80,80);
label.top(btex $\eightpoint s + t = 0$ etex, (-54,72));
label.bot(btex $\tenpoint -2$ etex, (-48,0));
label.bot(btex $\tenpoint -1$ etex, (-24,0));
label.rt(btex $\tenpoint 2$ etex, (0, 48));
label.rt(btex $\tenpoint 1$ etex, (0, 24));
begingroup interim
defaultscale:=3.6;
label.top("0", (-72,30));
label.top("?",(-24,30));
endgroup
endfig;
Notice the begingroup endgroup pair: at this point MetaPost is being left
on its own to select the font to draw the "0" and the "?" in, because I
did not specify that this be done with TeX. One of the TeXgang I THINK
then gets confused about what to do because the default font is a virtual
font, not a real font, by which I mean there is no entry in the various
.map files used by dvips for a font with the name "pgararm", and so in the
ultimate step of the process of creating a PostScrip file from the .dvi
file, dvips cops out with the rediculous error message:
! error while uncompressing; more bits ...
which really was no help at all in tracking down the error. Where in the
compilation chain involved in making this book one of the TeXgang could,
and should, have spit out a more sensible error message (such as pgararm
is not an acceptable font, or something similar) I am unsure. At least
dvips could have told me that it could not find the font "pgararm" which
might have helped me locate the error a bit sooner.
In any case removing the sequence
defaultfont = "pgararm";
from the file bookname.mp, and replacing it with an instruction to use the
actual, real, honest to god, garamond font (this time "embedded" in the
.mem file, so I do not make this error again (ha!)) "g003013t" as the
default font lets me create the PostScript file for the printer. In any
case, for the moment, things are compiling again. Happy Easter and until
the next error message I cannot decipher.
Larry Smith
PS Suggestions: add a proviso to the MetaPost documentation that the
default font ought to be something that dvips can find an entry for in its
tables of .map files.
Ask the maintainers of dvips to fix the error message if possible.